Re: RFC: Mark outer frames

[Joel Brobecker <brobecker@adacore.com>]

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