[patch RFC] Re: Notes on a frame_unwind_address_in_block problem

[Daniel Jacobowitz]

On Mon, Jan 01, 2007 at 09:26:45PM +0100, Mark Kettenis wrote:
> But if you're calling get_frame_func() you've already got a frame, so
> you should know everything about it.  The place to fix things is
> probably get_frame_address_in_block().  For one thing it's probably
> not a good idea to return an address that's lower than the code
> address in the frame ID.  Or perhaps it is enough to look at the
> frame's type and simply call frame_pc_unwind for SIGTRAMP_FRAMEs.

Hmm, get_frame_func may have been an ill-chosen example.  A better one
is frame_func_unwind.  get_frame_func just wraps frame_func_unwind, and
get_frame_address_in_block just wraps frame_unwind_address_in_block.  I
think that's a generally good thing - it encourages consistency in
their results.  The unwind variants are used all over GDB, not just
during unwinding; this matters e.g. around main, where get_prev_frame
might return NULL.

And that's why my solution ended up complicated.  When you're in
frame_func_unwind you have to call frame_unwind_address_in_block,
and at that point you might not know the type or even the unwinder
of the previous frame.

So I made frame_unwind_address_in_block do pretty much what you
suggested above, and forbid calling it before we know the type of the
previous frame.

> > Hmm... I don't think it's possible, but it depends what qualifier you
> > meant to put on "all targets".  The only way I can see to do it would
> > be with hand-written assembly and CFI and stack manipulation.  I might
> > be able to write a test which worked on all x86-64 systems and
> > pretended to have create a signal frame, if that's what you wanted.
> 
> Hmm, sorry yes, a test that would work on all i386 or x86-64 target
> was what I actually meant.

I can probably do that.  I'll try this evening.

-- 
Daniel Jacobowitz
CodeSourcery