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

[Jan Kratochvil <jan dot kratochvil at redhat dot com>]

On Thu, 23 Oct 2014 12:02:34 +0200, Alexandre Oliva wrote:
> dlinfo offers operations to both map a link_map (AKA dlopen handle) to
> the modid, and to get the TLS base address for that link_map.  I suppose
> calling dlinfo directly is not an option, since there's no guarantee
> that libdl will have been linked in.

Thanks for the dlinfo() information; but I agree libdl is not an option for
the "GDB JIT" purpose.


> However, the implementat of dlinfo RTLD_DI_TLS_DATA relies on
> _dl_tls_get_addr_soft, that not only takes a struct link_map*, but also
> refrains from assigning a TLS segment for the module in the running
> thread when one isn't allocated already.  I think this would be
> preferrable behavior for a debugger, to avoid heisenbugs.

OK, I will try to use _dl_tls_get_addr_soft for GDB as is.

Although I think the TLS segment allocation would be better for the "GDB JIT"
purpose.  Imagine an inferior shared library:
	__thread int tlsvar;
And user asking for:
(gdb) compile code tlsvar = 5;

I think it is better to do the TLS segment allocation than to refuse the
command to the user.  But someone may have an opposite opinion.


> This symbol is not exported by ld.so, but this shouldn't stop GDB from
> using it, since it is present in the symbol table as a local (hidden)
> symbol.

It is OK although when we talk about it it is not perfect.  Some distros strip
all shared libraries and then they have problem libthread_db cannot find
libpthread .symtab-only _thread_db_* symbols.  _dl_tls_get_addr_soft() will
have the same problem.  But that is mostly off-topic here now.


Thanks,
Jan