This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, Jul 27, 2006 at 12:15:29AM +0200, Mark Kettenis wrote:
> > 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.

I guess I was hoping we'd convinced you.  I demonstrated that at least
one of the architectures you listed as not having use for this
convention, under at least one operating system, actually did use it.
Jim and Joel and Andrew all piped up to support using it universally.

But if you're dead set against it, I don't see any way forward except
to concede.  This means I'm going to keep getting bug reports with the
same solutions on different architectures for a while :-(  Oh 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.
> > 
> > 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:

You're right - I thought there were far more than there actually are.
I guess this would work.

Maybe we need a few predicate functions for these types...

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

Andrew and I argued about this comment several times.  I disagree with
it, and in fact have various patches floating around to do similar
tests on more architectures.  It's an extremely useful technique, done
carefully.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]