[LLVMdev] [lld] Implementing the aliasing feature

Shankar Easwaran shankare at codeaurora.org
Fri Sep 13 16:16:41 PDT 2013



On 9/13/2013 6:06 PM, Nick Kledzik wrote:
> On Sep 13, 2013, at 3:35 PM, Shankar Easwaran <shankare at codeaurora.org> wrote:
>> This would work only if an alias is another name for the same symbol(weak symbols).
> I don’t know what that means. Can you clarify?
Doesnt this imply that the alias atom is a zero sized atom ?
>> If what is being aliased is another function definition, which is a non zero sized atom, aliasing will not work.
> That is the exact scenario I think it *will* work in.  What do you think won’t work.
If its a non zero sized atom, like for example :-

definedatoms:
    - name : fna
      size : 4
     ...
     ...

definedatoms:
    - name: fnb
      size: 4

If I alias the atom, and add a layoutBefore from *fna* to *fnb*, fnb is 
going to have a seperate virtualaddress from fna.

But you essentially wanted fna, fnb to have the same virtual address right ?

Am I misreading something that you said ?
>
>
>> I was thinking to model this for ELF for the below functionalities :-
>>
>> a) __wrap
>>
>> For example : --wrap fn
>>
>> What I plan to do here is,
>>
>> create a undefined function fn atom
>> create a defined weak atom fn
>> create a alias reference to __wrap_fn which is a undefined atom.
> I don’t see how those steps will achieve wrapping functionality.  Say you are wrapping malloc.  There will be a malloc seen at build time from libc, and all references to malloc will bind to it.  Adding alternate names won’t stop that binding.
Yes, thats how ld is behaving, if I have the the function in my .o's, it 
doesnot override.

For example :-

#include <stdio.h>

int myfn() {
   return 0;
}

void __wrap_myfn()
{
   printf("Hello World\n");
}

int main() {
   myfn();
   return 0;
}
$gcc wrap.c -Wl,--wrap,fn
$./a.out
$

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130913/743c1727/attachment.html>


More information about the llvm-dev mailing list