From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22772 invoked from network); 9 Feb 2022 22:32:12 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Feb 2022 22:32:12 -0000 Received: (qmail 18235 invoked by uid 550); 9 Feb 2022 22:32:09 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18215 invoked from network); 9 Feb 2022 22:32:08 -0000 Date: Wed, 9 Feb 2022 17:31:55 -0500 From: Rich Felker To: Florian Weimer Cc: Yehuda Yitchak , musl@lists.openwall.com Message-ID: <20220209223155.GD7074@brightrain.aerifal.cx> References: <20220209183326.GB7074@brightrain.aerifal.cx> <87h797zs6a.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87h797zs6a.fsf@oldenburg.str.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Accessing Thread-Local-Storage in GDB On Wed, Feb 09, 2022 at 09:44:13PM +0100, Florian Weimer wrote: > * Rich Felker: > > > On Wed, Feb 09, 2022 at 09:32:10AM +0200, Yehuda Yitchak wrote: > >> Hello > >> > >> one of the applications i am debugging is compiled using MUSL libc > >> (aarch64) Version 1.1.19 > >> when i inspect a core-dump and try to view TLS variables with "print > >> __percpu_dev" gdb (v8.3) complains: > >> > >> Cannot find thread-local storage for LWP 22873, executable file > >> > >> Cannot find thread-local variables on this target > >> > >> Any idea how I can overcome this? > >> Appreciate if you could CC me since i'm not subscribed. > > > > I think this is a consequence of gdb wanting to have a libthread_db (a > > GNU- and Solaris-ism) to tell it how to interact with the threads > > implementation of the process being debugged rather than just doing > > things in a libpthread-agnostic way like musl wants it to do. I think > > it should be fixable on the gdb side without too much headache, but I > > don't know how. > > GDB would have to poke at libc internals and basically reimplement > __tls_get_addr. Maybe something can be done by calling libc ABI > functions for TLS access instead, but that doesn't work for core files. For a live process it can just call __tls_get_addr in the inferior. I'm not sure what the best way for a core file is. > > As a workaround, if the program is dynamic-linked, you can do > > something like print *(int *)dlsym(0, "foo") from the relevant thread > > context and it should work. > > This only works if foo is a dynamic symbol (and if you aren't examining > a coredump). > > My interest in initial-exec TLS (despite its impact on dlopen) is > somewhat motivated by a desire to make things easier for debuggers. Indeed, I was just offering a quick workaround that might help, not suggesting gdb should do that. __tls_get_addr can be used for non-dynamic symbols with information already available to the debugger. For core files you could probably simulate execution and abort if anything is reached that would need to change process state (lazy allocation) although that doesn't happen with musl anyway. But I wonder if the core file even records the x86 segment information needed to preserve thread pointer and simulate the %fs/%gs based loads on x86[_64]..? Rich