Re: question about why gdb needs executable's binary

[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