[patch] Avoid aliases to weak aliases in interceptors

[Alexey Samsonov]

LGTM

While you're here, can you also
fix compiler-rt/lib/sanitizer_common/tests/sanitizer_allocator_testlib.cc
in the similar fashion?
Thanks!


On Wed, Mar 26, 2014 at 6:57 PM, Kostya Serebryany <kcc at google.com> wrote:

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


-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140326/a7aa0af1/attachment.html>