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
- From: Daniel Jacobowitz <drow at false dot org>
- To: Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 1 Jan 2007 15:02:48 -0500
- Subject: Re: [patch RFC] Re: Notes on a frame_unwind_address_in_block problem
- References: <20060706222157.GA1377@nevyn.them.org> <200607132020.k6DKKCSB023812@elgar.sibelius.xs4all.nl> <20060718183910.GB17864@nevyn.them.org> <20070101191927.GA14930@nevyn.them.org> <200701011954.l01Js85r031019@brahms.sibelius.xs4all.nl>
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