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

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Mon, 1 Jan 2007 15:02:48 -0500
> From: Daniel Jacobowitz <drow@false.org>
> 
> > making sure we set the right function address for signal trampolines?
> > That is, shouldn't we have a dwarf2_signal_frame_this_id() that
> > chooses a more sensible code address than frame_func_unwind()?
> 
> That would fix the failing tests, but I'm worried about problems
> elsewhere.  That's what I did in the patch I posted in July, I think.
> But get_frame_func would still return different values depending
> on whether the frame was topmost or not.  That's called all over GDB -
> I can't figure out whether it will leave other bugs for us to
> stumble on later.

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