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

Peter Collingbourne via llvm-commits llvm-commits at lists.llvm.org
Mon May 2 10:59:13 PDT 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160502/965edfb7/attachment.html>


More information about the llvm-commits mailing list