Re: frame cache

[Mark Kettenis <mark dot kettenis at xs4all dot nl>]

> Date: Mon, 30 Jul 2007 14:17:36 -0700
> From: Michael Eager <eager@eagercon.com>
> 
> >> I don't see where there is any test in symtab.c or infrun.c
> >> which tests for debug info before calling SKIP_PROLOGUE which
> >> calls <target>_skip_prologue.
> > 
> > Because if you want to use debugging information to skip prologue, you 
> > write the code in this function. So, test should be place here in this 
> > function.
> 
> As I mentioned, in x86 or PowerPC there is no code to bypass analyzing
> the prologue, even if there is debug info.  If prologue analysis is
> truly to be done "only as a last resort", and I agree that this should
> be the case, then this seems not to be represented in the gdb code.

In the context of the the frame cache, prologue analysis *is* only
done as a last resort for all targets that have DWARF CFI.  We have a
stack of unwinders, and run down that stack until we find an unwinder
that can handle a particular frame.  The unwinder that does the
prologue analysis comes last in that stack, after the DWARF unwinder.
So if there is DWARF CFI debug info for a frame, the prologue analysis
is never done.  Of course in practice you're probably running lots of
code that doesn't have debug info because many vendors install
stripped libraries.

Now on some targets we also do prologue analysis when placing a
breakpoint on a function.  In theory this should also be possible
using DWARF debug info, except that GCC doesn't (yet) provide that
information.  We used to do this using line number information (and on
some targets we still do that), but that became unreliable when the
compiler started to agressively reschedule prologue instructions.  And
then there were issues with the line number information generated by
GCC being wrong.  However, this is only done when setting breakpoints,
so it shouldn't really be happening that much, and therefore isn't
very performance critical.  It also doesn't really have anything to do
with the frame cache.

So I'm not really sure under which conditions you're observing the
excessive prologue analysis.  If you're seeing it during frame
unwinding, it might be worth investigating why the DWARF frame
unwinder doesn't handle things.  Perhaps you should consider
installing unstripped libraries, or seperate debug info for the
libraries on your system.  If you are seeing it when breakpoints get
set, it is probably worth working on getting GCC to emit the proper
debug info and implementing support for it in GDB.

Mark