This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb support for Linux vsyscall DSO
- From: Mark Kettenis <kettenis at chello dot nl>
- To: roland at redhat dot com
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 15 May 2003 23:25:43 +0200 (CEST)
- Subject: Re: gdb support for Linux vsyscall DSO
- References: <200305130153.h4D1rGW23237@magilla.sf.frob.com>
Date: Mon, 12 May 2003 18:53:16 -0700
From: Roland McGrath <roland@redhat.com>
> There is some special handling for signal trampolines in
> infrun.c:handle_inferior_event(). Beware! Dragons can still be found
> in that function. However, it seems the bit of code I'm talking about
> is there for targets that don't known how to properly unwind signal
> frames :-).
I only partly follow the code in that function, but it does look
like it wants to know whether it's in a signal frame. I get the
impression that "next" or "step" interrupted by a signal lets the
signal be handled and continues until the end of the source line
rather than doing a normal user stop for the signal, and that this
is considered desireable. So it must know.
I'm not really sure. The code I referred to seems to be written for
BSD-style signal trampolines, where the signal trampoline will call
the signal handler. The Linux kernel calls the signal trampoline
directly, so perhaps it doesn't need this code.
Having a DWARF2 extension to mark signal frames seems reasonable, and less
kludgey than matching symbol names. However, I wonder if there is in fact
a way to do it that won't confuse older libgcc's .eh_frame unwinding code.
If the `z' augmentation doesn't confuse older libgcc's, I don't see
why adding another augmentation would do so. But we should first
determine if we really need it before adding it.
> Restoring %eflags is certainly possible. Making GDB actually pop the
> signal trampoline frame should work
I only mentioned %eflags to pedantic because I caught myself about to say
"restore the exact state of the interrupted thread" and that wasn't
completely true. I don't anticipate gdb having any reason to want to roll
back a signal frame. (However, in the abstract it seems like the right
thing for the kernel unwind info to describe restoring %eflags if the
DWARF2 format can already represent that.)
Well, GDB will do exactly that when the user gives the "return"
command in a signal trampoline.
Mark