[patch] Avoid aliases to weak aliases in interceptors

[Kostya Serebryany]

On Wed, Mar 26, 2014 at 6:48 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> The interceptors have code that after macro expansion ends 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, the attached patch makes it more obvious what is
> going on. I found this when I disallowed alias to weak aliases in the
> IR, since there is no way to properly represent them in object files.
> In now realize that I also have to change clang to produce a clear
> error message, but we should probably fix compiler-rt first.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140326/01e883ab/attachment.html>