Re: question about why gdb needs executable's binary

["Jirka Koutný" <koutnji2@gmail.com>]

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
>