From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118862 invoked by alias); 13 Sep 2017 19:27:03 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 118835 invoked by uid 89); 13 Sep 2017 19:27:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=H*F:D*be, (unknown), life X-Spam-User: qpsmtpd, 2 recipients X-HELO: mailsec113.isp.belgacom.be Received: from mailsec113.isp.belgacom.be (HELO mailsec113.isp.belgacom.be) (195.238.20.109) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 13 Sep 2017 19:26:59 +0000 IronPort-PHdr: =?us-ascii?q?9a23=3ACN417Rb5Hy//sbiJGABzoYv/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZrsS9bnLW6fgltlLVR4KTs6sC0LuG9fi4EUU7or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6arXK99yMdFQviPgRp?= =?us-ascii?q?OOv1BpTSj8Oq3Oyu5pHfeQtFiT6+bL9oMBm6sRjau9ULj4dlNqs/0AbCrGFSe+?= =?us-ascii?q?RRy2NoJFaTkAj568yt4pNt8Dletuw4+cJYXqr0Y6o3TbpDDDQ7KG81/9HktQPC?= =?us-ascii?q?TQSU+HQRVHgdnwdSDAjE6BH6WYrxsjf/u+Fg1iSWIdH6QLYpUjm58axlVAHnhz?= =?us-ascii?q?sGNz4h8WHYlMpwjL5AoBm8oxBz2pPYbJ2JOPZ7eK7WYNEUSndbXstJVCJPH4Oy?= =?us-ascii?q?YZUBAeUDM+ZXs47zqFQBoxalGQmhB/nixiNSi3Pq36A31fkqHwHc3AwnGtIDqG?= =?us-ascii?q?7arNX0NKcWUOC11LHIwiveZPxWwzj98o/Icgk8ofGNQ71wa9HRwlQoGgPdjlWQ?= =?us-ascii?q?qIjlPzKN1uQVrWeX9eRhWvi1i24gsgFxvzmvydk2ionSnY8V0VPE9CV/wIkrOd?= =?us-ascii?q?20UlV0bsC9HZZWqiqUNJN2T9shTmxqoio3y78LtYSlcCQWypkr3QPTZv+JfoWO?= =?us-ascii?q?/xntTvyeIS1ii3JgYL+/ghGy/lW+xeDkTcm01UpKrjJCktnRqnABzxzT5daDSv?= =?us-ascii?q?t65kqh3CuA2xjS6uFCP080ibLWJp0jz7Iql5ces17PEjHqlEj0lqOaa0Yp9+aw?= =?us-ascii?q?5+TieLrmp5ucN4FuigH5N6QjgtS/AeQ5MggKXmib4fy826P58Uz3WrpKlPo2kr?= =?us-ascii?q?DEsJDbO8sbvLW5DhRO0oYg6xe/CSmp0MgCkXYcMl1JYAiHgJTxO1HSPPD4Cu+y?= =?us-ascii?q?g0y2nzdv2fDJIKbhD47XLnfdjbjhfaxy61JGxAUvytBf4opeCqsdL/LrRk/xqN?= =?us-ascii?q?vYAwc4MgOu3+nnC9t825gGWW2VBK+ZMazTvUWU6eIoJumGfJUVtyrlK/g5+/7u?= =?us-ascii?q?imc0mVscfaaywZQbcWq3HvB+I0WZe3XhmcwBEWAXvgokUOPlllODXiRJZ3msRa?= =?us-ascii?q?484Ss7CI2+B4fZWo+tmKCB3Du8HpBOaWBJF0uDHGzzd4WDRvcMcj6dLdFvkzMe?= =?us-ascii?q?T7iuVZUt1Ra0tA/1mPJbKb/s9yECstrK0MZ4/KWHjRg26zFvJ96Q32GEUyd/mW?= =?us-ascii?q?ZeA3cE1at86XNwy1GJ3LJ3y6hKHNdQ+NtRWwE7JdjXyOksWP7oXQeURteITFe+?= =?us-ascii?q?WtjuPjgrScsswtIUeA4pA9WjihHbxyfsHLYPkKWWBZEu6YrH3Gn3Kto7wXuQh/?= =?us-ascii?q?pptEUvXsYabT7uvaV47QWGQteRy0g=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2C4AgCNhblZ/7fPQ1ddGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBFQEBAQECAQEBAQgBAQEBgy8lP4EVgyxLixWRJi8BmAoKG4UjAoRUQxU?= =?us-ascii?q?BAQEBAQEBAQEBAWoogjMkAYJBAQUjDwEjIxAIAw4KAgIfBwICOR4GASuKHK1Fg?= =?us-ascii?q?ieLLgEBAQEGAgElgQ6CHYNSgWODKIRiCYMggmEFoHmCLoUtjHiCbpAGSJRogTk?= =?us-ascii?q?1IoENdIYwgVA+Nokggj8BAQE?= X-IPAS-Result: =?us-ascii?q?A2C4AgCNhblZ/7fPQ1ddGgEBAQECAQEBAQgBAQEBFQEBAQE?= =?us-ascii?q?CAQEBAQgBAQEBgy8lP4EVgyxLixWRJi8BmAoKG4UjAoRUQxUBAQEBAQEBAQEBA?= =?us-ascii?q?WoogjMkAYJBAQUjDwEjIxAIAw4KAgIfBwICOR4GASuKHK1FgieLLgEBAQEGAgE?= =?us-ascii?q?lgQ6CHYNSgWODKIRiCYMggmEFoHmCLoUtjHiCbpAGSJRogTk1IoENdIYwgVA+N?= =?us-ascii?q?okggj8BAQE?= Received: from 183.207-67-87.adsl-dyn.isp.belgacom.be (HELO md) ([87.67.207.183]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 13 Sep 2017 21:26:32 +0200 Message-ID: <1505330791.1896.10.camel@skynet.be> Subject: 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 To: Pedro Alves , Zack Weinberg Cc: GNU C Library , gdb@sourceware.org Date: Wed, 13 Sep 2017 19:27:00 -0000 In-Reply-To: <72a8ac9b-2429-c8bd-83b9-d758224571c5@redhat.com> References: <20170622224456.1358-1-zackw@panix.com> <3a7946e9-d178-f878-9774-64ff44bcf5df@redhat.com> <9490d183-a57b-b336-3131-6580e4773818@redhat.com> <2f28f69b-406f-65e5-40e1-ae65632ea4f0@redhat.com> <1d38297f-f430-ca73-6d3f-a67144d08eea@redhat.com> <7348d7d9-b339-b14f-3dea-31d17c996a2a@redhat.com> <4ed368f7-4469-4a49-c4e3-0c3afc18c121@redhat.com> <2432779a-f146-1612-236e-84dde15c5d01@redhat.com> <72a8ac9b-2429-c8bd-83b9-d758224571c5@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg00035.txt.bz2 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