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

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

> Date: Mon, 24 Jul 2006 15:32:45 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sat, Jul 22, 2006 at 01:22:53PM +0200, Mark Kettenis wrote:
> > 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.
> 
> I'm fine with this; it seems easy enough to work with.  Have you got
> any other conventions in mind?  For functions which might use the DWARF
> unwinder, I've only seen the return address undefined convention (which
> we basically made up), and the PC == 0 convention.  We could implement
> e.g. %ebp == 0, but you've pointed out that it can misfire with
> -fomit-frame-pointer.

On ISA/ABI's with a "hard" frame pointer, FP == 0 is a widely used
convention, i.e. %fp == 0 on sparc and sparc64.  For i386, where %ebp
== 0 no longer works because the compiler people realized it isn't a
"fard" frame pointer, a condition like %eip == 0 && %ebp == 0 might
actually be workable.  For some operating systems we might even want
to look the function name.

> Where would the PC==0 test be applied?  I and several others in
> this thread have said that it makes sense in every case for every
> platform - that's why I wanted it in frame.c, rather than in each
> individual unwinder.  I can't tell from this paragraph whether we've
> convinced you, or whether you would push it out to the individual
> architectures to decide.  I'm unhappy with individual architecture
> knobs for basically the same reason we've agreed it shouldn't be a user
> knob.

I though I have been very clear: PC == 0 is unacceptable as a generic
condition for terminating stack frames.  So yes, this will be pushed
into the individual architectures.  That's good since it forces people
to think about the proper termination condition for their ISA/ABI.

> > 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.
> 
> I suspect that OUTERMOST_FRAME would be a lot of trouble.  There's a
> lot of checks on frame types that look for "abnormal" frames via
> ->type != NORMAL_FRAME; but a function called by an OUTERMOST_FRAME was
> a normal call, just like a function called by a NORMAL_FRAME.  That's
> why I suggested a new unwinder method in struct frame_unwind.

Actually there is only a limited number of such tests in our tree: a
couple of them in frame.c, and two in s390-tdep.c.  Many of the checks
in frame.c actually deal with stuff that we might want to do
differently for OUTERMOST_FRAME.  The checks in s390-tdep.c both have
this FIXME on them:

  /* FIXME: cagney/2004-05-01: This sanity check shouldn't be needed,
     instead the code should simpliy rely on its analysis.  */

Mark