Re: [libc patch] __tls_get_addr with link_map * instead of modid

[Rich Felker <dalias@libc.org>]

On Sat, Oct 18, 2014 at 10:15:40PM +0200, Jan Kratochvil wrote:
> Hi,
> 
> https://sourceware.org/glibc/wiki/Tools%20Interface%20NG
> 	From within the inferior: Functions that are inserted into a process's
> 	address space by the debugger need to be able to access the TLS area
> 	for that thread. GDB can use DWARF to to find the offset within the
> 	TLS of a variable and pass that in as a compile time offset into the
> 	function being inserted into the traced process's address space.
> 	However, to be able to get to the address of the TLS area for
> 	a particular thread, it needs to know the module id to make a call to
> 	__tls_get_addr(). This module id is burried in a private area of the
> 	link_map data structure which is subject to change. It is therefore
> 	proposed that we add a new function to libthread_db which extracts the
> 	module id from the link map. 
> 
> Other option suggested by Tom Tromey is implemented by this patch:
> 
> * A new glibc function like __tls_get_addr that takes a link_map address
>   rather than a module id.

This sounds more appealing. I don't know how much interest you have in
non-glibc systems, but from our side with musl libc, we presently
don't have a libthread_db and don't plan to, so anything that makes
gdb work better without it (or even just preserves current
functionality without it) is preferable.

> I expect I will have to also implement this Tom Tromey's suggestion to GDB but
> I haven't tried to implement it yet:
> 
> * Bake more information about struct link_map into gdb (least preferred
>   IMO).

I think this is the worst option.

> Additionally one could also fetch the module id from R_X86_64_DTPMOD64 but that
> would require arch specific code in GDB.  I do not plan to implement this way.

I don't see how this would work; how would you request the dynamic
linker to resolve that for you?

Rich