[libc patch] __tls_get_addr with link_map * instead of modid
Thu Oct 23 12:52:00 GMT 2014
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)
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.
More information about the Gdb-patches