This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFC: Mark outer frames
- From: Joel Brobecker <brobecker at adacore dot com>
- To: gdb-patches at sourceware dot org
- Date: Wed, 2 Sep 2009 10:03:24 -0700
- Subject: Re: RFC: Mark outer frames
- References: <20090828213237.GA9175@caradoc.them.org>
FWIW:
> The obvious pitfall is that the outer frame isn't a single consistent
> frame. So there's an ugly bit in infrun that says if we set the stack
> pointer while inside an outer frame, and suddenly we're in a frame we
> think we can unwind from (mostly incorrectly at this point), then
> we've not changed functions. Otherwise stepping through _start will
> blow up on some platforms I tried.
Didn't we have the same problem with null_frame_id before? I guess
not because equality to the null_frame_id is always false... The bit
in infrun does not seem all that horrible to me, but your comment does
suggest another way that you might think is better?
> Thoughts? Does this actually help with 9711? Is it too ugly to live?
This does not strike me as something that would set us back in terms
of maintenance. I like the idea of splitting null_frame_id in two
different entities with a narrower meaning. The heuristic in infrun
is a little unfortunate, but not the worse I've seen by a large measure.
I would personally be OK with that patch, especially if it's useful to
others (Doug, for instance).
+ /* The outermost frame marker is equal to itself. This is the
+ dodgy think about outer_frame_id, since between execution steps
^^^^^ thing
I wouldn't mind a more detailed comment about when outer_frame_id
should be used (we're in startup code and the associated frame has
not been setup yet). I got confused by "there is no frame ID, but
there is a frame".
--
Joel