Re: [RFC] Using values to handle unwinding

[Daniel Jacobowitz <drow@false.org>]

On Fri, Oct 19, 2007 at 01:41:50PM +0200, Ulrich Weigand wrote:
> >       if (get_frame_type (next_frame) == NORMAL_FRAME)
> >         return 0;

> Well, we can always just use "get_next_frame (this_frame)" instead
> of next_frame.   Getting the next frame is always well-defined.

Right.  get_next_frame fails when the next frame is the sentinel
frame, so it is not always useful if you need a frame that you can
pass to a frame_unwind_* routine.  But it never fails if
frame->next->type would be NORMAL_FRAME.

> > I noticed this while looking at m68k-elf backtraces.  It would be nice
> > to add a check like the above, either there or somewhere more generic,
> > because otherwise a garbage stack pointer leads to a near-infinite
> > backtrace.  Any time that the current frame's PC points to somewhere
> > GDB has no symbol info, GDB will conclude that there is a frameless
> > function which only stored its return address on the stack at the
> > call.  So each word of the stack is popped in turn and becomes a new
> > PC.  Not very useful!
> 
> Yes, situations similar to that were what prompted my addition of the
> above sanity check (Andrew's comment nonwithstanding :-/).

The m68k check turns out to be particularly thorny; this is a problem
with architectures where call pushes onto the stack.  You can't
distinguish that from any other stack push, so all frames are assumed
to have a valid return address as long as the stack is readable.

I'm speculating about a "set backtrace max-uncertainty" and
frame_is_uncertain ()... or "set backtrace aggressive off"...

We shouldn't give up when we have no symbol information if the
architecture claims to know how to handle that case.  This happens
when crashing in a stripped shared library, for instance, and on
i386 GNU/Linux GDB generally manages a useful backtrace anyway.

Anyway, that's unrelated to this patch.  I'll save it for another
day :-)

-- 
Daniel Jacobowitz
CodeSourcery