Re: musl can't handle gold's STB_LOCAL TLS symbols

[Rich Felker <dalias@libc.org>]

On Thu, May 23, 2019 at 05:47:13PM -0700, Ryan Prichard wrote:
> I noticed that if I use a version script with ld.gold to make a TLS symbol
> in a DSO local, the symbol remains in the .dynsym table but with local
> binding. Gold emits DTPMOD/DTPOFF relocations to the local TLS symbol, and
> when musl tries to load the DSO, it apparently tries to look up the symbol
> name globally and fails.
> 
> $ cat vers
> {
> global:
>   get_tls_var;
> local:
>   *;
> };
> 
> $ cat dso.c
> __thread int tlsvar;
> int get_tls_var(void) {
>   return tlsvar;
> }
> 
> $ cat main.c
> int get_tls_var(void);
> int main() {
>   get_tls_var();
>   return 0;
> }
> 
> $ musl-gcc dso.c -fpic -shared -fuse-ld=gold -Wl,-version-script=vers -o
> libdso.so
> $ musl-gcc main.c libdso.so -Wl,-rpath,'$ORIGIN' -o main
> $ ./main
> Error relocating /tmp/local-tls-symbol/libdso.so: tlsvar: symbol not found
> Error relocating /tmp/local-tls-symbol/libdso.so: tlsvar: symbol not found
> 
> $ readelf -rW --dyn-syms libdso.so
> ....
> 0000000000001fd8  0000000100000010 R_X86_64_DTPMOD64      0000000000000000
> tlsvar + 0
> 0000000000001fe0  0000000100000011 R_X86_64_DTPOFF64      0000000000000000
> tlsvar + 0
> ....
>      1: 0000000000000000     4 TLS     LOCAL  DEFAULT   13 tlsvar
> ....
> 
> The test program works with ld.bfd, because ld.bfd converts the DTPMOD
> relocation to 0 and omits the DTPOFF relocation. There was a somewhat
> similar issue with gold+musl involving a DTPMOD relocation to a
> local section symbol, https://sourceware.org/bugzilla/show_bug.cgi?id=17699.
> That issue prompted a thread on the generic-abi group,
> https://groups.google.com/d/topic/generic-abi/dJ4_Y78aQ2M/discussion.
> 
> I'm wondering if this problem is a bug in musl or gold. I also wonder if

I would consider this a bug in gold. There is no reason to leave local
symbols unresolved until runtime; resolving them is ld's whole job.

> DTPOFF can reference a TLS section, even though the value of a TLS section
> symbol isn't suitable for DTPOFF unless it's first adjusted by the
> segment's p_vaddr.

I don't see a good reason for it to reference a section either. It
should just have a 0 symbol reference, and store the ld-determined
offset to the object in the addend. Any kind of symbolic reference
here is just going to be a waste of time doing a lookup at runtime.

Rich