[patch RFC] Re: Notes on a frame_unwind_address_in_block problem

[Mark Kettenis]

> Date: Wed, 3 Jan 2007 11:12:57 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Wed, Jan 03, 2007 at 12:37:00PM +0100, Mark Kettenis wrote:
> > The basic principle of unwinding is that you get information about
> > THIS_FRAME from NEXT_FRAME; you always walk the frame chain in one
> > direction.  This means that the only requirement for calling
> > frame_unwind_xxx functions is that you have a NEXT_FRAME.  Your change
> > introduces a function that breaks this rule, by requiring THIS_FRAME
> > to be there, walking the frame chain in the other direction.  And it
> > didn't take you very long to hit the problem with that: infinite
> > recursion.
> > 
> > Now the problem we're facing is that frame_unwind_address_in_block()
> > (frame_func_unwind() is nothing but a fancy wrapper around that call)
> > cannot be implemented reliably without knowledge about THIS_FRAME; it
> > needs to know whether THIS_FRAME could be a fake frame set up by the
> > kernel in order to determine whether it is a good idea to adjust the
> > unwound PC or not.  In our current implementation that information is
> > carried by the frame type.
> > 
> > The solution I think, is to pass this information explicitly to
> > frame_unwind_address_in_block(), i.e. we change it's prototype from:
> 
> I've hit one hiccup with this... dwarf2_frame_this_id isn't calling
> frame_unwind_address_in_block, just frame_func_unwind.  So, if
> we want frame_func_unwind to do the right thing, that's the
> call site which needs to know the right frame type.

Oh sorry Daniel, I thought it was obvious that frame_func_unwind()
needed the same treatment as frame_unwind_address_in_block().

Mark