RFC: Mark outer frames
Joel Brobecker
brobecker@adacore.com
Wed Sep 2 17:03:00 GMT 2009
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
More information about the Gdb-patches
mailing list