Re: [RFC] Move the frame zero PC check earlier

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Thu, 18 May 2006 19:30:17 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Thu, May 18, 2006 at 10:04:09PM +0200, Mark Kettenis wrote:
> > If we're sure that zero return address actually signals the end of the
> > stack, then indeed we should not print the extra frame.  I'm not
> > arguing with that.  But that's defenitely 
> 
> Incomplete sentence?  But, I think there was enough context.

Think I wanted to say something like:

...not the only case where we see a zero pc.

> > Many systems, but certainly not all systems.  At least i386, amd64,
> > sparc and sparc64 don't use this convention.
> 
> I hate to break it to you but... that's not 100% true.  Most psABI
> documents don't cover clean stack ending, so operating systems often
> have to pick their own (or sometimes they do specify it and OS's go off
> and do their own thing anyway, I expect).  I've just checked, and
> sparc-vxworks definitely does end backtraces for kernel mode tasks by
> setting the return address to 0 before it spawns a new task.

Interesting because sparc is one of the few architectures that has a
framepointer register that you can't use for something else, such that
the a "zero framepointer" convention would actually work reliably.
Also not that on sparc we can actually unwind past a zero return
address as long as the frame pointer chain is still intact.

> i386-vxworks sets %ebp to zero to indicate the end of the stack, I
> believe.

This is the traditional way to signal the end of the stack.
Unfortunately GCC's move towards generating framepointer-less code,
makes this convention pretty much useless.  On i386, we should
probably move towards setting both %eip and %ebp to zero to indicate
the end of the stack.

> I checked RTEMS too, but the results were somewhat inconclusive; I'm
> not sure it deliberately initializes all registers.  That was an
> educational dive through RTOS source, though.

What really matters, is whether the threads library marks the end of
stack properly.  For the main thread, we usually end the backtrace at
main() (or its equivalent) and people debugging the startup code that
runs before main() probably now what they're doing.

Mark