This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [obish?sym;rfa:doc] Wire up vsyscall
On Mon, May 10, 2004 at 11:40:01PM +0200, Mark Kettenis wrote:
> Date: Mon, 10 May 2004 17:27:51 -0400
> From: Andrew Cagney <cagney@gnu.org>
>
> > On Thu, May 06, 2004 at 04:54:55PM -0400, Andrew Cagney wrote:
> >
> >>>> >At present I know of the following problems:
> >>
> >>>
> >>> 4. backtrace changes:
> >>>
> >>> #0 handler (sig=26, info=0xfeed7c50, context=0xfeed7cd0) at
> >>> /home/cygnus/cagney
> >>> /PENDING/2004-05-06-add-vsyscall/src/gdb/testsuite/gdb.base/siginfo.c:31
> >>> #1 0x0093e440 in __kernel_sigreturn ()
> >>> #2 0x0804848a in main () at
> >>> /home/cygnus/cagney/PENDING/2004-05-06-add-vsyscall
> >>> /src/gdb/testsuite/gdb.base/siginfo.c:66
> >>>
> >>> vs
> >>>
> >>> #0 handler (sig=26, info=0xfee1ea80, context=0xfee1eb00) at
> >>> /home/cygnus/cagney
> >>> /GDB/src/gdb/testsuite/gdb.base/siginfo.c:31
> >>> #1 <signal handler called>
> >>> #2 0x0804848a in main () at
> >>> /home/cygnus/cagney/GDB/src/gdb/testsuite/gdb.base/
> >>>
> >>> but remember I intend changing the second to:
> >>>
> >>> ...
> >>> #1 0x1234 in <signal trampoline>
> >>> ...
> >
> >
> > In the meantime, here's the patch from my Debian backport which should
> > fix this. Pending a way to indicate 'abnormal frame' status in the
> > CFI, we don't want to use it; frame_unwind_address_in_block will hit.
> > 2004-01-25 Daniel Jacobowitz <drow@mvista.com>
>
> Even with the above frame display change, this is needed. The frame
> needs to identify it's type as SIGTRAMP_FRAME.
>
> Mark?
>
> Hmm. The DWARF CFI in the vsyscall DSO is deliberately generated such
> that frame_unwind_in_block does the right thing (there is a nop in
> front of __kernel_sigreturn, which is included in the FDE range, such
> that us substracting one from the PC will still give us the right
> Dwarf CFI).
That's not the only place where you have to worry about
frame_unwind_address_in_block. The other one is in the code that was
interrupted by the signal. If __kernel_sigreturn appears to be a
normal frame, then we will subtract one to find the block of
__kernel_sigreturn's "caller", which will move us before the beginning
of the function if we got the signal during the first instruction
(which happens in the GDB testsuite, which is how I noticed the
problem).
> To what extent do we need to know about SIGTRAMP_FRAME for other
> purposes? I guess we need it to get stepping into/through signal
> trampolines working properly, but I'd like to be certain about it.
I'm not sure we'll need it for that also. Maybe, but no reason jumps
out at me.
--
Daniel Jacobowitz