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 24314 invoked from network); 9 Feb 2022 18:33:42 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Feb 2022 18:33:42 -0000 Received: (qmail 1173 invoked by uid 550); 9 Feb 2022 18:33:39 -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 1141 invoked from network); 9 Feb 2022 18:33:39 -0000 Date: Wed, 9 Feb 2022 13:33:26 -0500 From: Rich Felker To: Yehuda Yitchak Cc: musl@lists.openwall.com Message-ID: <20220209183326.GB7074@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: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. 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. Rich