This is the mail archive of the
mailing list for the GDB project.
Re: [FYI] Inlining support, rough patch
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 30 Jun 2009 18:49:59 +0200
- Subject: Re: [FYI] Inlining support, rough patch
- References: <20080718130308.GA19045@caradoc.them.org> <200807251446.m6PEkfwc027635@brahms.sibelius.xs4all.nl> <20080725174636.GB2433@caradoc.them.org> <firstname.lastname@example.org> <200903312042.n2VKgIUx003764@brahms.sibelius.xs4all.nl> <20090420154909.GA5386@caradoc.them.org> <20090420155405.GA6072@host0.dyn.jankratochvil.net> <20090627180122.GA6139@caradoc.them.org> <20090628101621.GA31457@host0.dyn.jankratochvil.net> <email@example.com>
On Tue, 30 Jun 2009 18:11:14 +0200, Tom Tromey wrote:
> Alexandre Oliva has talked about something similar -- a dwarf extension
> which would let gdb users "step" through a sequence of source statements,
> even when the compiler has optimized them away.
.debug_loc key (+any attributes referencing PC) would need to not to state
only PC but a PC + sourceline pair. In an extreme case during the debugging
session PC does not need to change and no ptrace() needs to be called.
> I'm wondering about things like multiple levels of inlining (you may
> need several do-nothing steps?);
This part is step_into_inline_frame() already in the FSF GDB HEAD by Daniel J.
> multiple levels of inlining where the user wants to "finish" out of each one
> (you may need a do-nothing finish as well?); or inlining that results in
> a tail-call optimization being applied (there's no good spot to return to).
This is a Fedora extension of the patch by step_out_of_inline_frame() there.
Just I find .debug_line from GCC wrong a bit but I hope it gets fixed by the
is_stmt + VTA gcc patches so I have not bugreported the current state.