[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 :-

    - name : fna
      size : 4

    - 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() {
   return 0;
$gcc wrap.c -Wl,--wrap,fn


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