Skip to content
Commit 5e460705 authored by Rafael Espindola's avatar Rafael Espindola
Browse files

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
parent ab5633b7
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment