From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Mark Kettenis Cc: cagney@gnu.org, gdb-patches@sources.redhat.com, roland@redhat.com Subject: Re: [obish?sym;rfa:doc] Wire up vsyscall Date: Tue, 11 May 2004 14:53:00 -0000 Message-id: <20040511145344.GA15501@nevyn.them.org> References: <409A8C2A.2010605@gnu.org> <409AA61F.8050807@gnu.org> <20040507012549.GA30182@nevyn.them.org> <409FF3D7.5000106@gnu.org> <200405102140.i4ALe13A001092@elgar.kettenis.dyndns.org> X-SW-Source: 2004-05/msg00330.html 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 > > > 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 > >>> #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 > >>> ... > > > > > > 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 > > 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