Re: RFC: Mark outer frames

[Daniel Jacobowitz <drow@false.org>]

On Wed, Sep 02, 2009 at 10:03:24AM -0700, Joel Brobecker wrote:
> > 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?

Sorry, I meant to go into that.

The magic outer frame ID is, IMO, a workaround.  What we really want
is to have frame IDs wherever we can.  Either "stack address
uncertain, but function known" or even "stack address and function
known, but outerness detected".  This requires changes to the
unwinding interface, and additional changes to each affected unwinder
to build the best IDs we can and to mark the outer frame some other
way.

I haven't spec'd out a full approach to this problem, just speculated
about it.

> +    /* The outermost frame marker is equal to itself.  This is the
> +       dodgy think about outer_frame_id, since between execution steps
>               ^^^^^ thing
> 

Thanks!

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

This is, indeed, the central problem.

-- 
Daniel Jacobowitz
CodeSourcery