[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190524011204.GE23599@brightrain.aerifal.cx>
Date: Thu, 23 May 2019 21:12:04 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl can't handle gold's STB_LOCAL TLS symbols
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
