mailing list of musl libc
 help / color / mirror / code / Atom feed
* [musl] Accessing Thread-Local-Storage in GDB
@ 2022-02-09  7:32 Yehuda Yitchak
  2022-02-09 18:33 ` Rich Felker
  0 siblings, 1 reply; 7+ messages in thread
From: Yehuda Yitchak @ 2022-02-09  7:32 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

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.

Thanks
Yehuda

[-- Attachment #2: Type: text/html, Size: 632 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Accessing Thread-Local-Storage in GDB
  2022-02-09  7:32 [musl] Accessing Thread-Local-Storage in GDB Yehuda Yitchak
@ 2022-02-09 18:33 ` Rich Felker
  2022-02-09 20:44   ` Florian Weimer
  0 siblings, 1 reply; 7+ messages in thread
From: Rich Felker @ 2022-02-09 18:33 UTC (permalink / raw)
  To: Yehuda Yitchak; +Cc: musl

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.

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Accessing Thread-Local-Storage in GDB
  2022-02-09 18:33 ` Rich Felker
@ 2022-02-09 20:44   ` Florian Weimer
  2022-02-09 22:31     ` Rich Felker
  0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2022-02-09 20:44 UTC (permalink / raw)
  To: Rich Felker; +Cc: Yehuda Yitchak, musl

* 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.

> 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.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Accessing Thread-Local-Storage in GDB
  2022-02-09 20:44   ` Florian Weimer
@ 2022-02-09 22:31     ` Rich Felker
  2022-02-10 11:23       ` Florian Weimer
  0 siblings, 1 reply; 7+ messages in thread
From: Rich Felker @ 2022-02-09 22:31 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Yehuda Yitchak, musl

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

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Accessing Thread-Local-Storage in GDB
  2022-02-09 22:31     ` Rich Felker
@ 2022-02-10 11:23       ` Florian Weimer
  2022-02-10 18:05         ` Yehuda Yitchak
  0 siblings, 1 reply; 7+ messages in thread
From: Florian Weimer @ 2022-02-10 11:23 UTC (permalink / raw)
  To: Rich Felker; +Cc: Yehuda Yitchak, musl

* Rich Felker:

> 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]..?

The register is available as $fs_base on x86-64:

(gdb) print (void *)$fs_base
$1 = (void *) 0x7f2d12981740
(gdb) print *(void **)$fs_base
$2 = (void *) 0x7f2d12981740

It probably does not work on i386 (even as $gs_base).  I do not think it
depends on FSGSBASE support in the kernel, but maybe I'm mistaken.  I
think I looked at this three years ago and couldn't make it work.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Accessing Thread-Local-Storage in GDB
  2022-02-10 11:23       ` Florian Weimer
@ 2022-02-10 18:05         ` Yehuda Yitchak
  2022-02-10 21:32           ` Rich Felker
  0 siblings, 1 reply; 7+ messages in thread
From: Yehuda Yitchak @ 2022-02-10 18:05 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Rich Felker, musl

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

I forgot to mention I work on arm64
I guess there isn't much I can do at the moment, right ?

On Thu, Feb 10, 2022, 13:23 Florian Weimer <fweimer@redhat.com> wrote:

> * Rich Felker:
>
> > 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]..?
>
> The register is available as $fs_base on x86-64:
>
> (gdb) print (void *)$fs_base
> $1 = (void *) 0x7f2d12981740
> (gdb) print *(void **)$fs_base
> $2 = (void *) 0x7f2d12981740
>
> It probably does not work on i386 (even as $gs_base).  I do not think it
> depends on FSGSBASE support in the kernel, but maybe I'm mistaken.  I
> think I looked at this three years ago and couldn't make it work.
>
> Thanks,
> Florian
>
>

[-- Attachment #2: Type: text/html, Size: 1603 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [musl] Accessing Thread-Local-Storage in GDB
  2022-02-10 18:05         ` Yehuda Yitchak
@ 2022-02-10 21:32           ` Rich Felker
  0 siblings, 0 replies; 7+ messages in thread
From: Rich Felker @ 2022-02-10 21:32 UTC (permalink / raw)
  To: Yehuda Yitchak; +Cc: Florian Weimer, musl

On Thu, Feb 10, 2022 at 08:05:15PM +0200, Yehuda Yitchak wrote:
> I forgot to mention I work on arm64
> I guess there isn't much I can do at the moment, right ?

If you're debugging live processes not core files, the dlsym approach
may work for you.


> On Thu, Feb 10, 2022, 13:23 Florian Weimer <fweimer@redhat.com> wrote:
> 
> > * Rich Felker:
> >
> > > 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]..?
> >
> > The register is available as $fs_base on x86-64:
> >
> > (gdb) print (void *)$fs_base
> > $1 = (void *) 0x7f2d12981740
> > (gdb) print *(void **)$fs_base
> > $2 = (void *) 0x7f2d12981740
> >
> > It probably does not work on i386 (even as $gs_base).  I do not think it
> > depends on FSGSBASE support in the kernel, but maybe I'm mistaken.  I
> > think I looked at this three years ago and couldn't make it work.
> >
> > Thanks,
> > Florian
> >
> >

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2022-02-10 21:32 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-09  7:32 [musl] Accessing Thread-Local-Storage in GDB Yehuda Yitchak
2022-02-09 18:33 ` Rich Felker
2022-02-09 20:44   ` Florian Weimer
2022-02-09 22:31     ` Rich Felker
2022-02-10 11:23       ` Florian Weimer
2022-02-10 18:05         ` Yehuda Yitchak
2022-02-10 21:32           ` Rich Felker

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).