[rfc, frame] Add backtrace stop reasons

[Daniel Jacobowitz]

Hi Mark, thanks for looking at these.

On Sun, Aug 20, 2006 at 04:38:19PM +0200, Mark Kettenis wrote:
> > A nice bonus, in my opinion: if the backtrace stops because unwinding
> > detects an error or the end of the stack, "info frame" will explain
> > why.  For instance:
> > 
> >   Stops backtrace: previous frame inner to this frame (corrupt stack?)
> 
> Is this really useful?  It adds an extra line to the "info frame"
> output, which might mean that more useful information about the frame
> scrolls of my screen :(.

(gdb) info frame
Stack level 0, frame at 0xbf8e5838:
 eip = 0xffffe410 in __kernel_vsyscall; saved eip 0xb7ea61cb
 called by frame at 0xbf8e5850
 Arglist at 0xbf8e5830, args:
 Locals at 0xbf8e5830, Previous frame's sp is 0xbf8e5838
 Saved registers:
  ebp at 0xbf8e5828, eip at 0xbf8e5834

Where are we really in danger of this scrolling off the screen?  Frames
with dozens of arguments (which generally wouldn't stop the backtrace
anyway, so wouldn't have the line)?  I can imagine reasons to dislike
adding more information, but I confess this one confuses me a bit :-)

I think it will be useful, especially as the set of reasons grows.
As you correctly noticed, the other patches don't fundamentally
depend on this one, but I did them in this order deliberately;
two later followups could be converting the zero PC check to use a stop
reason, and allowing the architecture unwinders to return stop reasons.
Backtrace would print out the "error" reasons, but not the "normal"
reasons; you could look in info frame for the "normal" reasons, like
"Unwinding indicated no return address" for the undefined retaddr
column markers we use in DWARF-2.

> The implementation looks good to me, but I don't see why we need this
> functionality yet.  Can you hold on to this until we really need it?

If you want; there's no point in this unless at least one of the other
patches goes in.

The problem with holding things until we really need them is that we
build up these huge queues of patches related to a single project.
I'm sure this code wouldn't turn into abandonware.  But it's a small
patch, so I can easily carry it along until we're ready for it if you
prefer.

-- 
Daniel Jacobowitz
CodeSourcery