This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Move the frame zero PC check earlier
- From: Daniel Jacobowitz <drow at false dot org>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: andrew dot stubbs at st dot com, gdb-patches at sourceware dot org
- Date: Mon, 24 Jul 2006 15:32:45 -0400
- Subject: Re: [RFC] Move the frame zero PC check earlier
- References: <446C3EB3.1040606@st.com> <vt2fyj7l1fe.fsf@theseus.home.> <1147969938.3672.168.camel@dufur.beaverton.ibm.com> <vt2wtcjjjc2.fsf@theseus.home.> <200605182004.k4IK49Eh003764@elgar.sibelius.xs4all.nl> <vt2mzdfjam5.fsf@theseus.home.> <200605202129.k4KLT4g4014877@elgar.sibelius.xs4all.nl> <20060521020434.GA9432@nevyn.them.org> <44C0F828.4090807@st.com> <200607221122.k6MBMrdP000084@elgar.sibelius.xs4all.nl>
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