Re: [rfc, frame] Add backtrace stop reasons

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

> Date: Sun, 20 Aug 2006 12:28:21 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> 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 :-)

But you're cheating by choosing an example from a register-starved
architecture ;-)  Here's the output on 64-bit SPARC:

Stack level 2, frame at 0xfffffffffffc8cc0:
 pc = 0x100a54 in main (../../../../src/gdb/gdb/testsuite/gdb.base/run.c:63); 
    saved pc 0x1007b8
 caller of frame at 0xfffffffffffc8bf0
 source language c.
 Arglist at 0xfffffffffffc8cc0, args: argc=2, argv=0xfffffffffffc8e08, 
    envp=0xfffffffffffc8e20
 Locals at 0xfffffffffffc8cc0, Previous frame's sp in fp
 Saved registers:
  l0 at 0xfffffffffffc8cc0, l1 at 0xfffffffffffc8cc8, l2 at 0xfffffffffffc8cd0,
  l3 at 0xfffffffffffc8cd8, l4 at 0xfffffffffffc8ce0, l5 at 0xfffffffffffc8ce8,
  l6 at 0xfffffffffffc8cf0, l7 at 0xfffffffffffc8cf8, i0 at 0xfffffffffffc8d00,
  i1 at 0xfffffffffffc8d08, i2 at 0xfffffffffffc8d10, i3 at 0xfffffffffffc8d18,
  i4 at 0xfffffffffffc8d20, i5 at 0xfffffffffffc8d28, fp at 0xfffffffffffc8d30

It's not yet a screenful, but already getting close.  I think I've
seen even worse on 64-bit MIPS, but indeed it is not too bad yet.

But I guess I'd really wanted to point out that we should be careful
about printing out too much information.  On the other hand we would
only print the additionol info for the last frame on the chain.  It's
my feeling though that "Stops backtrace" does not indicate a property
of the frame like the other things we print.  But printing something
like "Outermost frame: unwinding indicated no return address".  sounds
better to me.

What do other people think?

> 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.

I think we can work something out that we both agree on pretty soon,
at least for this part

Mark