Re: GDB support for thread-local storage

[Jim Blandy <jimb at redhat dot com>]

Daniel Berlin <dberlin@dberlin.org> writes:
> > The function one may need to invoke to find thread-local storage,
> > __tls_get_addr, is an actual native code function, in the dynamic
> > linker.  The DW_OP_call_* operations allow a Dwarf expression to call
> > another Dwarf expression like a function.  But you can't use the
> > DW_OP_call_* operations to invoke machine-language functions in the
> > inferior.
> 
> You've assumed you need to.
> If you can transform tls_get_addr into a dwarf expression, there you go.
> You can deref memory, you just can't store into it.
> Since the TLS address is just a location somewhere, computed without 
> modifying anything, one should be able to transform it pretty easily.
> 
> Not that this is the best idea, but it's a possibility.
> :)

We did try to find a way to just express this as a Dwarf expression,
before we resorted to a custom opcode and a libthread_db function.

One objection was that this would embed knowledge about the
implementation of TLS in the executable's debugging info.  The way to
find TLS can change depending on which dynamic linker and thread
library you happen to be (dynamically) linking against.  The process
for finding TLS really should be tightly coupled with the actual
dynamic linker and thread library in use, the way libthread_db is.

One could put the right Dwarf expression in the thread library or
dynamic linker's debugging info, and use DW_OP_call* to invoke it that
way --- that would get the coupling right.  But GDB doesn't apply
dynamic relocs to its debugging info (and it's hard to see exactly how
it could without a lot more help from the dynamic linker --- see Uli's
TLS paper).  This makes it hard to get the right operand for the
DW_OP_call4/8/whathaveyou.

There is also another problem I didn't mention.  You need to know the
module number in order to look up its TLS.  The dynamic linker doesn't
assign the module a number until it's loaded.  But perhaps the Dwarf
expression could actually get that from a GOT entry.