Avoid aliases to weak aliases in interceptors.

The interceptors had code that after macro expansion ended up looking like

extern "C" void memalign()
    __attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
    __attribute__((alias("memalign")));

That is,
* __interceptor_memalign is a function
* memalign is a weak alias to __interceptor_memalign
* __interceptor___libc_memalign is an alias to memalign

Both gcc and clang produce assembly that look like

__interceptor_memalign:
...
        .weak   memalign
memalign = __interceptor_memalign
        .globl  __interceptor___libc_memalign
__interceptor___libc_memalign = memalign

What it means in the end is that we have 3 symbols pointing to the
same position in the file, one of which is weak:

     8: 0000000000000000     1 FUNC    GLOBAL DEFAULT    1
__interceptor_memalign
     9: 0000000000000000     1 FUNC    WEAK   DEFAULT    1 memalign
    10: 0000000000000000     1 FUNC    GLOBAL DEFAULT    1
__interceptor___libc_memalign

In particular, note that __interceptor___libc_memalign will always
point to __interceptor_memalign, even if we do link in a strong symbol
for memalign. In fact, the above code produces exactly the same binary
as

extern "C" void memalign()
    __attribute__((weak, alias("__interceptor_memalign")));
extern "C" void __interceptor_memalign() {}
extern "C" void __interceptor___libc_memalign()
    __attribute__((alias("__interceptor_memalign")));

If nothing else, this patch makes it more obvious what is going on.

llvm-svn: 204823

0 files changed, 0 insertions, 0 deletions