Re: GDB reading eh_frame/eh_frame_hdr from disk

On Fri, 19 Jun 2020 00:37:42 +0200, Mitch Souders wrote:
> Is there any way to tell gdb to use the in-memory representation from the
> inferior of the .eh_frame/.eh_frame_hdr sections when doing stack
> unwinding? As best I can determine, gdb always reaches out to disk to find
> .eh_frame/.eh_frame_hdr to do stack unwinding. Our product is doing some
> runtime manipulation of these sections and gdb's current behavior is
> undesired.

I am not aware GDB (nor LLDB) could do that. elfutils stack (eu-stack) can do
that. One can test it by deleting the file on disk (such as during update of
a running daemon) and backtrace it.


Jan


$ cp -p /bin/sleep /tmp/xsleep;/tmp/xsleep 1m&p=$!;rm -f /tmp/xsleep;eu-stack -p $p;kill $p
PID 3471191 - process
TID 3471191:
#0  0x00007f127d3c581e clock_nanosleep@@GLIBC_2.17
#1  0x00007f127d3cb1c7 __nanosleep
#2  0x0000558ca6adba67 rpl_nanosleep
#3  0x0000558ca6adb829 xnanosleep
#4  0x0000558ca6ad87f0 main
#5  0x00007f127d324042 __libc_start_main
#6  0x0000558ca6ad88ce _start

$ cp -p /bin/sleep /tmp/xsleep;/tmp/xsleep 1m&p=$!;rm -f /tmp/xsleep;gdb -p $p -batch -ex bt;kill $p
warning: Could not load vsyscall page because no executable was specified
0x00007f36db01881e in ?? ()
#0  0x00007f36db01881e in ?? ()
#1  0x0000000000000000 in ?? ()
[Inferior 1 (process 3471210) detached]