Re: [patch RFC] Re: Notes on a frame_unwind_address_in_block problem

[Daniel Jacobowitz <drow@false.org>]

On Wed, Jan 03, 2007 at 12:37:00PM +0100, Mark Kettenis wrote:
> If you think a bit further (almost) all cases where we currently call
> frame_unwind_address_in_block() in sniffers, we really need to specify
> THIS_FRAME's type explicitly.  So signal frame sniffers would need to
> do call frame_unwind_address_in_block (next_frame, SIGTRAMP_FRAME).
> Doing so in the dwarf2_signal_frame_this_id() would fix the bug we're
> trying to fix.

That's much more elegant than what I had.  Thanks a lot!  I'll try it.
In dwarf2_frame_cache I'll need to fetch the type from THIS
frame; normally unwinders avoid looking at that, but there's no
iron reason why they must, so it should be fine.

I think that this will convert most calls to either pass NORMAL_FRAME
or call the non-unwind version - there's a lot of potential call sites
which call frame_pc_unwind instead, because they know that the function
doesn't do anything for signal frames, so there won't be any hardcoded
uses of the unwind version with SIGNAL_FRAME.

-- 
Daniel Jacobowitz
CodeSourcery