GDB reading eh_frame/eh_frame_hdr from disk

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

GDB reading eh_frame/eh_frame_hdr from disk

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

--
-Mitch
Reply | Threaded
Open this post in threaded view
|

Re: GDB reading eh_frame/eh_frame_hdr from disk

Simon Marchi-4
On 2020-06-18 6:37 p.m., 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.

If the section is allocated in the process, then I'd expect GDB to read
it from memory (when there's a process).  You would need to step into
GDB when it's doing one such read to see which target ends up handling
the memory read.

Simon
Reply | Threaded
Open this post in threaded view
|

Re: GDB reading eh_frame/eh_frame_hdr from disk

Sourceware - gdb list mailing list
In reply to this post by Mitch Souders
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]

Reply | Threaded
Open this post in threaded view
|

Re: GDB reading eh_frame/eh_frame_hdr from disk

Sourceware - gdb list mailing list
In reply to this post by Simon Marchi-4
The command:

set trust-readonly-sections [on|off]

toggles reading from memory vs reading from disk. The default is off, so
unless you have a weird target or a strange script, you should be getting
it from memory already. But it isn't hard to change to see if that fixes
your problem.



On Mon, Jun 22, 2020 at 11:08 AM Simon Marchi <[hidden email]> wrote:

> On 2020-06-18 6:37 p.m., 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.
>
> If the section is allocated in the process, then I'd expect GDB to read
> it from memory (when there's a process).  You would need to step into
> GDB when it's doing one such read to see which target ends up handling
> the memory read.
>
> Simon
>
Reply | Threaded
Open this post in threaded view
|

Re: GDB reading eh_frame/eh_frame_hdr from disk

Simon Marchi-4
In reply to this post by Sourceware - gdb list mailing list
On 2020-06-22 2:14 p.m., Jan Kratochvil via Gdb wrote:

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

Ah, I guess it's because these sections are read by dwarf/read.c from the BFD
directly, these reads don't pass through target_ops?

Simon
Reply | Threaded
Open this post in threaded view
|

Re: GDB reading eh_frame/eh_frame_hdr from disk

Sourceware - gdb list mailing list
On Mon, 22 Jun 2020 20:17:47 +0200, Simon Marchi wrote:
> Ah, I guess it's because these sections are read by dwarf/read.c from the BFD
> directly, these reads don't pass through target_ops?

Yes, it just cannot work.  IIRC I was implementing into elfutils extra code
path to decode eh_frame from program headers (instead of section headers which
are not available in memory) for deleted debuggees.


Jan