[lld] r268178 - ELF: New symbol table design.

[Rafael Espíndola via llvm-commits]

I can reproduce this. Creating a small testcase.

On 2 May 2016 at 13:59, Peter Collingbourne via llvm-commits
<llvm-commits at lists.llvm.org> wrote:
> On Mon, May 2, 2016 at 6:25 AM, Ed Schouten <ed at nuxi.nl> wrote:
>>
>> Hi Peter,
>>
>> 2016-05-01 6:55 GMT+02:00 Peter Collingbourne via llvm-commits
>> <llvm-commits at lists.llvm.org>:
>> > ELF: New symbol table design.
>>
>> Sweet! Thanks for working on this.
>>
>> While testing this change, I think I ran into a small (potential)
>> regression. If I create a statically linked, position independent
>> executable that contains some TLS symbols, I now get the following
>> error messages:
>>
>> $ cat hello.c
>> #include <stdio.h>
>> int main() {
>>   dprintf(1, "Hello\n");
>> }
>> $ x86_64-unknown-cloudabi-cc -o hello hello.c
>> TLS attribute mismatch for symbol: errno in (internal) and
>>
>> /usr/local/llvm-trunk/bin/../x86_64-unknown-cloudabi/lib/libc.a(src_libc_locale_ctype_us_ascii.o)
>> TLS attribute mismatch for symbol: errno in (internal) and
>>
>> /usr/local/llvm-trunk/bin/../x86_64-unknown-cloudabi/lib/libc.a(src_libc_errno_errno.o)
>> TLS attribute mismatch for symbol: __pthread_wrlocks in (internal) and
>>
>> /usr/local/llvm-trunk/bin/../x86_64-unknown-cloudabi/lib/libc.a(src_libc_pthread_pthread_rwlock_wrlock.o)
>> TLS attribute mismatch for symbol: __pthread_wrlocks in (internal) and
>>
>> /usr/local/llvm-trunk/bin/../x86_64-unknown-cloudabi/lib/libc.a(src_libc_pthread_pthread_wrlocks.o)
>> TLS attribute mismatch for symbol: __pthread_rdlocks in (internal) and
>>
>> /usr/local/llvm-trunk/bin/../x86_64-unknown-cloudabi/lib/libc.a(src_libc_pthread_pthread_rwlock_unlock.o)
>> TLS attribute mismatch for symbol: __pthread_rdlocks in (internal) and
>>
>> /usr/local/llvm-trunk/bin/../x86_64-unknown-cloudabi/lib/libc.a(src_libc_pthread_pthread_rdlocks.o)
>> clang-3.9: error: linker command failed with exit code 1 (use -v to
>> see invocation)
>>
>> With the previous revision of LLD, r268172, the executable seems to
>> link properly. Would you by any chance know what's causing this? Is
>> there any more debug info you're interested in?
>
>
> I'm not sure, but I have my suspicions. Would it be possible to create a
> reproducer with the new --reproduce flag? (Pass -Wl,--reproduce,somedir to
> the compiler and send a tarball of somedir).
>
> Thanks,
> --
> Peter
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>