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

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

> Date: Fri, 21 Jul 2006 16:52:08 +0100
> From: Andrew STUBBS <andrew.stubbs@st.com>
> 
> This is a feature I would like to see.

Thanks Andrew, for reminding us.

> Daniel Jacobowitz wrote:
> > On Sat, May 20, 2006 at 11:29:04PM +0200, Mark Kettenis wrote:
> >> I actually think that something like that is the way to go.  It's
> >> closely related to what Dan wrote about in:
> >>
> >> http://sourceware.org/ml/gdb/2006-05/msg00109.html
> >>
> >> and I'd like to have a go at implementing option #2 in that mail.
> > 
> > That (the frame unwinder end-of-stack method) wouldn't actually help
> > with this problem; that's why I sent the two separately (they were
> > originally the same message when I was writing it).  The architecture
> > unwinder could report a saved pc of zero as terminating the stack, but
> > in all the cases I'm interested in, the DWARF-2 unwinder is actually
> > used for the bottom frame.

But the "having a saved pc of zero" is only one of the conventions
used for terminating the frame chain.  So the DWARF-2 unwinder would
still fail to do the right thing for ISA/ABI's that use a different
convention.  So I think we need an ISA/ABI-specefic callback to
determine whether a frame is the outermost frame, just like we already
have for signal trampolines.  This actually matches the following idea
I had pretty well:

The outermost frame is special, just like sigtramp and dummy frames.
Why not introduce a new frame type OUTERMOST_FRAME and make
get_prev_frame() return NULL if that's the type of THIS_FRAME's?  This
would require some changes to the current frame unwinder
infrastructure, since the type is currently hardcoded into the
unwinder.  That would have the additional benefit that we could get
rid of the bogosity that we have multiple frame unwinder definitions
in the DWARF-2 unwinder just to handle signal trampolines.

Thoughts?

Mark