From mboxrd@z Thu Jan  1 00:00:00 1970
From: Mark Kettenis <kettenis@chello.nl>
To: cagney@gnu.org
Cc: drow@false.org, gdb-patches@sources.redhat.com, roland@redhat.com
Subject: Re: [obish?sym;rfa:doc] Wire up vsyscall
Date: Tue, 11 May 2004 05:15:00 -0000
Message-id: <200405102140.i4ALe13A001092@elgar.kettenis.dyndns.org>
References: <409A8C2A.2010605@gnu.org> <409AA61F.8050807@gnu.org> <20040507012549.GA30182@nevyn.them.org> <409FF3D7.5000106@gnu.org>
X-SW-Source: 2004-05/msg00325.html

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

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.

Mark