This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] Attach vsyscall support for GNU/Linux
- From: Mark Kettenis <kettenis at gnu dot org>
- To: drow at false dot org
- Cc: gdb-patches at sources dot redhat dot com, ezannoni at redhat dot com, cagney at gnu dot org, roland at redhat dot com
- Date: Mon, 1 Nov 2004 21:45:20 +0100 (CET)
- Subject: Re: [rfa] Attach vsyscall support for GNU/Linux
- References: <20041024185345.GB22700@nevyn.them.org> <200410242054.i9OKsjnl028328@elgar.sibelius.xs4all.nl> <20041024231636.GA21927@nevyn.them.org> <200410252212.i9PMCQhJ031724@elgar.sibelius.xs4all.nl> <20041101161552.GA26993@nevyn.them.org>
Date: Mon, 1 Nov 2004 11:15:52 -0500
From: Daniel Jacobowitz <drow@false.org>
On Tue, Oct 26, 2004 at 12:12:26AM +0200, Mark Kettenis wrote:
> Date: Sun, 24 Oct 2004 19:16:36 -0400
> From: Daniel Jacobowitz <drow@false.org>
>
> Thanks for the explanation Daniel!
>
> Unwinding bugs aside, I think it's valuable for GDB to know that it is
> at a signal trampoline. I think the custom display in backtrace is
> valuable. That means we should look for signal handlers before looking
> for CFI. For NPTL that value judgement would fall the other way - not
> having to special-case signal handlers is a clear win.
>
> Given the fact that it is desirable for GDB to know that it's dealing
> with a signal handler, I think the correct approach is to extend the
> DWARF2 unwinder with a method to get the frame type, similar to what
> we already do for pre-initializing the register state.
>
> I'll see if I can come up with a patch for you to test.
Had any time for this, Mark? If not, I can try it.
I forgot about it :-(. I had a look just now, but unfortunately it's
not as easy as I thought. The frame type is currently hard-coded in
the unwinder. This is wrong, but Andrew thinks it's wrong in a
different way than I. At least, that's what I think. I'll have to
learn reading UML diagrams first. I'll throw some Feynman diagrams
into my next mail to get even with him ;-). This is not going to be a
simple fix, therefore...
I think this patch is very important for 6.3.
...you might want to convince Andrew to include your origional patch
in 6.3. Or better yet, a patch that prepends a signal frame unwinder
only for Linux. If you succeed, you have my blessing to check this in
on mainline too, provided you add a big fat warning why this is done
and that it's so wrong.
Sorry,
Mark