This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch RFC] Re: Notes on a frame_unwind_address_in_block problem
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