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.

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).

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 have failed to test this patch on ia64 as I have available only RHEL-5 which
has too old ld and then I gave it up on too old Linux kernel include files.

I haven't written any GDB support for this patch yet.


Thanks,
Jan