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

[Daniel Jacobowitz <drow@false.org>]

On Mon, Jan 01, 2007 at 08:54:08PM +0100, Mark Kettenis wrote:
> Well, I really can't say I like it.  The problem is that it's been
> several months since we last discussed this problem, so I'll have to
> start to think again from scratch :(.  Isn't it just a matter of

Yeah, sorry about that.  Anyway, I'm happy to discuss alternatives;
I don't like it much either.

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

> Optimist!  We'll only have to wait for the GCC/glibc/kernel people to
> come up with the next smart hack that they don't bother to test GDB
> with and you'll have lots of failures to fix again ;-)

Well yeah :-)  But the first step in keeping up is definitely catching
up.

> But we have no stand-alone testcase.  You really need the right
> version of glibc to be able to test this.  Could you come up with a
> testcase that works everywhere, or at least on all targets?

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.

-- 
Daniel Jacobowitz
CodeSourcery