[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Feb 2022 17:31:55 -0500
From: Rich Felker <dalias@...c.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: Yehuda Yitchak <yehuda80@...il.com>, musl@...ts.openwall.com
Subject: Re: 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
> >> <core-dump-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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
