Re: [RFC] Using values to handle unwinding

["Ulrich Weigand" <uweigand@de.ibm.com>]

Daniel Jacobowitz wrote:

> There is one current use I know of for the NEXT_FRAME argument to
> unwinders, in s390-tdep.c:
> 
>       /* If the next frame is a NORMAL_FRAME, this frame *cannot* have frame
>          size zero.  This is only possible if the next frame is a sentinel
>          frame, a dummy frame, or a signal trampoline frame.  */
>       /* FIXME: cagney/2004-05-01: This sanity check shouldn't be
>          needed, instead the code should simpliy rely on its
>          analysis.  */
>       if (get_frame_type (next_frame) == NORMAL_FRAME)
>         return 0;
> 
> Maybe this means we should either find a generic place to do this sort
> of check, or pass both this and next frame, or leave the frame
> argument alone after all.  Or add a new frame function, like
> "frame_called_normally (this_frame)" which seems to be the question
> people are really asking when they write code like the above.

Well, we can always just use "get_next_frame (this_frame)" instead
of next_frame.   Getting the next frame is always well-defined.
So I don't think this influences the this_frame vs. next_frame
discussion one way or the other ...

> 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 :-/).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com