This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: question about why gdb needs executable's binary
- From: Jirka Koutný <koutnji2 at gmail dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb at gnu dot org
- Date: Tue, 19 Mar 2019 14:25:15 +0000
- Subject: Re: question about why gdb needs executable's binary
- References: <CAH5nFm8dpqyFWuttO+aZOCBAAMjEeuEtv=xwhyFjjMpu8cTs3g@mail.gmail.com> <20190314214555.GA2221061@host1.jankratochvil.net>
Sorry for the delay, I needed some time to read up on DT_DEBUG and r_debug.
It makes a little bit more sense now, so thanks a lot. If you find time,
I'd still like to ask a few more questions:
PT_NOTE can't be read by gdb, that settles it, thanks *thumb up*. That
being said, how about dlopen()? How do these get in the trace? Surely not
from the executable.
For what I found out about DT_DEBUG this section gets initialized by ld as
you said. Do I understand you correctly, this is an alternative to the
first option, that in fact doesn't require the executable?
Thank you
Jirka
Den tor. 14. mar. 2019 kl. 21:45 skrev Jan Kratochvil <
jan.kratochvil@redhat.com>:
> On Wed, 13 Mar 2019 15:24:50 +0100, Jirka Koutný wrote:
> > I was wondering why does gdb still need the executable's binary as well?
> > Is there some additional information retrieved from the executable?
>
> Yes, without the main executable GDB cannot find the list of shared
> libraries.
>
>
> > PT_NOTE contains address ranges and shared libraries names as well,
>
> NT_FILE is a recent feature and GDB can only produce it, GDB cannot read
> it.
> GDB also cannot read /proc/PID/maps to recognize the list of shared
> libraries.
>
>
> > What is the missing bit of information there?
>
> To find the list of mapped shared libraries GDB needs to read DT_DEBUG
> which
> is located in DYNAMIC segment of the main executable.
>
> GDB can read also "_r_debug" but for that it needs to know ld.so which is
> a mapped shared library so that is a chicked-and-egg problem.
>
>
> eu-stack can do these:
>
> With main executable:
> $ eu-stack --core=sleep.core
> PID 1886638 - core
> TID 1886638:
> #0 0x00007f37e04707f8 __nanosleep
> #1 0x000055a9557f28d7 rpl_nanosleep
> #2 0x000055a9557f26b0 xnanosleep
> #3 0x000055a9557ef7c8 main
> #4 0x00007f37e03cb413 __libc_start_main
> #5 0x000055a9557ef89e _start
>
> Without main executable:
> $ eu-stack --core=sleep.core2
> PID 1886638 - core
> TID 1886638:
> #0 0x00007f37e04707f8 __nanosleep
> #1 0x000055a9557f28d7
> eu-stack: dwfl_thread_getframes tid 1886638 at 0x55a9557f28d6 in
> /usr/bin/sleep: Callback returned failure
>
> Just that eu-stack does not contain heuristics for unwinding frames with
> missing unwind information (.eh_frame/.debug_frame) and so if a frame is
> generated from the main executable it gives up for further unwinding.
>
>
> Jan
>