This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [libc patch] __tls_get_addr with link_map * instead of modid
- From: Rich Felker <dalias at libc dot org>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: libc-alpha at sourceware dot org, gdb-patches at sourceware dot org
- Date: Sat, 18 Oct 2014 17:20:48 -0400
- Subject: Re: [libc patch] __tls_get_addr with link_map * instead of modid
- Authentication-results: sourceware.org; auth=none
- References: <20141018201540 dot GA26252 at host2 dot jankratochvil dot net>
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