Re: Using libthread_db.so with single-threaded programs, for TLS access (was: Re: [RFC PATCH 0/3] Pretty-printing for errno)
Philippe Waroquiers <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.alpha,gmane.comp.gdb.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 2017-09-13 at 12:22 +0100, Pedro Alves wrote: > On 09/07/2017 12:34 PM, Pedro Alves wrote: > > On 09/06/2017 10:03 PM, Zack Weinberg wrote: > > > > > So, changes to both gdb and libthread_db seem to be required > > > here. I > > > do think that _in principle_ it ought to be possible to use > > > libthread_db to retrieve the address of thread-local data even if > > > the > > > inferior is not linked with libpthread; glibc has quite a few > > > thread-specific variables (errno most prominent, of course, but > > > also > > > h_errno, _res, etc), and so might any library which can be used > > > from > > > both single- and multithreaded programs. > > > > > > This is really not code I feel comfortable hacking up, though, > > > and > > > it's probably more of a project than I have time for, in any > > > case. > > > > Sounds like a promising approach though. I'd like to see this path > > explored a bit more. I'll keep this in my TODO, even though it's > > not likely to bubble up very soon. Thanks for the > > discussion/ideas! > > So I played with this a bit more on the plane back from Cauldron, > to try to see if we'd hit some major roadblock. I also chatted > with Carlos a bit about this back at the Cauldron, and seemingly > there's no major reason this can't be made to work, > TLS-internals-wise. > > Seems like that it's mainly a case of moving libthread_db.so-related > symbols from libpthread.so elsewhere. More below. Note that in the valgrind gdbserver, I had to handle the same problem i.e. find the address of a tls variable without access to any library (valgrind cannot make use of any library including glibc). So, I finally end-ed up implementing the minimum logic for that. It is based on some real ugly hacks, e.g. to get the offset of lm_modid in struct link_map. There is also some arch dependent 1 or 2 lines of code to get the dtv. This is all somewhat fragile, was done in 2014, not broken (yet). But some more recent changes might have broken the hack, as I have a test failing after upgrading to Debian 9. See valgrind coregrind/m_gdbserver/server.c handling of qGetTLSAddr for the gory/hacky details. Better (even partial) support for such things without the need of a library would significantly improve my life :) Philippe