[PATCH 01/12] Handle another edge case for TLS variable lookups.

[John Baldwin]

On 3/23/22 2:00 PM, John Baldwin wrote:
> This is similar to the change in
> df22c1e5d53c38f38bce6072bb46de240f9e0e2b but applies to the main
> object file.  The original change I encountered when testing TLS on
> RISC-V for which I was unable to test TLS variables in the main
> executable due to issues with compiler-generated debug info, so I only
> checked for a backlink before walking the list of shared library
> object files.
> 
> However, I ran into this issue again (of a separate debug object file
> being passed to svr4_fetch_objfile_link_map) when testing TLS
> variables on 32-bit arm.  To fix, move the check for a backlink
> earlier before the check for the main object file.

I now see this when using a separate debug file on FreeBSD/amd64 as
well FWIW.  This definitely used to work but now needs this fix for
me.  Curiously, 'info address' shows the variable belonging to the
separate debug file, e.g.:

% gdb tls tls.core
...
(gdb) info address id
Symbol "id" is a thread-local variable at offset 0x0 in the thread-local storage for `/usr/home/john/work/johnsvn/test/tls/tls.debug'.

Arguably this is a recent bug somewhere in the DWARF parsing that
is longer following the backlink when choosing the object file
for a TLS variable?  I think fixing svr4_fetch_objfile_link_map to
be resilient against this is still ok, but it might be worth
tracking down the other bug as well.  I'll see if I can find it.

-- 
John Baldwin