This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Using libthread_db.so with single-threaded programs, for TLS access (was: Re: [RFC PATCH 0/3] Pretty-printing for errno)
- From: Philippe Waroquiers <philippe dot waroquiers at skynet dot be>
- To: Pedro Alves <palves at redhat dot com>, Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, gdb at sourceware dot org
- Date: Wed, 13 Sep 2017 21:26:31 +0200
- Subject: Re: Using libthread_db.so with single-threaded programs, for TLS access (was: Re: [RFC PATCH 0/3] Pretty-printing for errno)
- Authentication-results: sourceware.org; auth=none
- Ironport-phdr: 9a23:CN417Rb5Hy//sbiJGABzoYv/LSx+4OfEezUN459isYplN5qZrsS9bnLW6fgltlLVR4KTs6sC0LuG9fi4EUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRpOOv1BpTSj8Oq3Oyu5pHfeQtFiT6+bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPCTQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhzsGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7WYNEUSndbXstJVCJPH4OyYZUBAeUDM+ZXs47zqFQBoxalGQmhB/nixiNSi3Pq36A31fkqHwHc3AwnGtIDqG7arNX0NKcWUOC11LHIwiveZPxWwzj98o/Icgk8ofGNQ71wa9HRwlQoGgPdjlWQqIjlPzKN1uQVrWeX9eRhWvi1i24gsgFxvzmvydk2ionSnY8V0VPE9CV/wIkrOd20UlV0bsC9HZZWqiqUNJN2T9shTmxqoio3y78LtYSlcCQWypkr3QPTZv+JfoWO/xntTvyeIS1ii3JgYL+/ghGy/lW+xeDkTcm01UpKrjJCktnRqnABzxzT5daDSvt65kqh3CuA2xjS6uFCP080ibLWJp0jz7Iql5ces17PEjHqlEj0lqOaa0Yp9+aw5+TieLrmp5ucN4FuigH5N6QjgtS/AeQ5MggKXmib4fy826P58Uz3WrpKlPo2krDEsJDbO8sbvLW5DhRO0oYg6xe/CSmp0MgCkXYcMl1JYAiHgJTxO1HSPPD4Cu+yg0y2nzdv2fDJIKbhD47XLnfdjbjhfaxy61JGxAUvytBf4opeCqsdL/LrRk/xqNvYAwc4MgOu3+nnC9t825gGWW2VBK+ZMazTvUWU6eIoJumGfJUVtyrlK/g5+/7uimc0mVscfaaywZQbcWq3HvB+I0WZe3XhmcwBEWAXvgokUOPlllODXiRJZ3msRa484Ss7CI2+B4fZWo+tmKCB3Du8HpBOaWBJF0uDHGzzd4WDRvcMcj6dLdFvkzMeT7iuVZUt1Ra0tA/1mPJbKb/s9yECstrK0MZ4/KWHjRg26zFvJ96Q32GEUyd/mWZeA3cE1at86XNwy1GJ3LJ3y6hKHNdQ+NtRWwE7JdjXyOksWP7oXQeURteITFe+WtjuPjgrScsswtIUeA4pA9WjihHbxyfsHLYPkKWWBZEu6YrH3Gn3Kto7wXuQh/pptEUvXsYabT7uvaV47QWGQteRy0g=
- References: <20170622224456.1358-1-zackw@panix.com> <b2e7bc3b-d914-37ec-0215-2937949a848c@redhat.com> <3a7946e9-d178-f878-9774-64ff44bcf5df@redhat.com> <9490d183-a57b-b336-3131-6580e4773818@redhat.com> <be8d9730-96c5-79fa-b9bc-2afc02a17ddf@redhat.com> <CAKCAbMgAwZOG95hpAAAVYJd4SP6j3aAahOf=WWedjNJkj7_JsA@mail.gmail.com> <2f28f69b-406f-65e5-40e1-ae65632ea4f0@redhat.com> <CAKCAbMj8Rf374bss0ct+H+XMOu_o+_WWR2mQ-s8fb4-3_d7GjA@mail.gmail.com> <1d38297f-f430-ca73-6d3f-a67144d08eea@redhat.com> <d9fc4b9d-21b9-98fb-c87a-38b2e0587a9a@redhat.com> <7348d7d9-b339-b14f-3dea-31d17c996a2a@redhat.com> <CAKCAbMjbN9jQEjVg-0VQVV+QXP+J93wSkqZ=WC1-MDM4a4v=mQ@mail.gmail.com> <4ed368f7-4469-4a49-c4e3-0c3afc18c121@redhat.com> <CAKCAbMgsHH9bJCgELWY6R9sWaZvdqGjdfUFDLihx3mor8HofGw@mail.gmail.com> <edcfb9d0-248c-fa10-583d-9a0512e4b091@redhat.com> <CAKCAbMiN0sBmb3BvSyfLANBT5GgD2LB6sASFZ8WPv5JZqMpapg@mail.gmail.com> <2432779a-f146-1612-236e-84dde15c5d01@redhat.com> <72a8ac9b-2429-c8bd-83b9-d758224571c5@redhat.com>
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