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

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.

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

-- 
Daniel Jacobowitz
CodeSourcery


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