* GDB reading eh_frame/eh_frame_hdr from disk
@ 2020-06-18 22:37 Mitch Souders
2020-06-22 18:08 ` Simon Marchi
2020-06-22 18:14 ` Jan Kratochvil
0 siblings, 2 replies; 6+ messages in thread
From: Mitch Souders @ 2020-06-18 22:37 UTC (permalink / raw)
To: gdb
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GDB reading eh_frame/eh_frame_hdr from disk
2020-06-18 22:37 GDB reading eh_frame/eh_frame_hdr from disk Mitch Souders
@ 2020-06-22 18:08 ` Simon Marchi
2020-06-22 18:16 ` Sterling Augustine
2020-06-22 18:14 ` Jan Kratochvil
1 sibling, 1 reply; 6+ messages in thread
From: Simon Marchi @ 2020-06-22 18:08 UTC (permalink / raw)
To: Mitch Souders, gdb
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GDB reading eh_frame/eh_frame_hdr from disk
2020-06-22 18:08 ` Simon Marchi
@ 2020-06-22 18:16 ` Sterling Augustine
0 siblings, 0 replies; 6+ messages in thread
From: Sterling Augustine @ 2020-06-22 18:16 UTC (permalink / raw)
To: Simon Marchi; +Cc: Mitch Souders, gdb
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 <simark@simark.ca> 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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GDB reading eh_frame/eh_frame_hdr from disk
2020-06-18 22:37 GDB reading eh_frame/eh_frame_hdr from disk Mitch Souders
2020-06-22 18:08 ` Simon Marchi
@ 2020-06-22 18:14 ` Jan Kratochvil
2020-06-22 18:17 ` Simon Marchi
1 sibling, 1 reply; 6+ messages in thread
From: Jan Kratochvil @ 2020-06-22 18:14 UTC (permalink / raw)
To: Mitch Souders; +Cc: gdb
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]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GDB reading eh_frame/eh_frame_hdr from disk
2020-06-22 18:14 ` Jan Kratochvil
@ 2020-06-22 18:17 ` Simon Marchi
2020-06-22 18:20 ` Jan Kratochvil
0 siblings, 1 reply; 6+ messages in thread
From: Simon Marchi @ 2020-06-22 18:17 UTC (permalink / raw)
To: Jan Kratochvil, Mitch Souders; +Cc: gdb
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GDB reading eh_frame/eh_frame_hdr from disk
2020-06-22 18:17 ` Simon Marchi
@ 2020-06-22 18:20 ` Jan Kratochvil
0 siblings, 0 replies; 6+ messages in thread
From: Jan Kratochvil @ 2020-06-22 18:20 UTC (permalink / raw)
To: Simon Marchi; +Cc: Mitch Souders, gdb
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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-06-22 18:20 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-18 22:37 GDB reading eh_frame/eh_frame_hdr from disk Mitch Souders
2020-06-22 18:08 ` Simon Marchi
2020-06-22 18:16 ` Sterling Augustine
2020-06-22 18:14 ` Jan Kratochvil
2020-06-22 18:17 ` Simon Marchi
2020-06-22 18:20 ` Jan Kratochvil
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).