Re: [obish?sym;rfa:doc] Wire up vsyscall

[Daniel Jacobowitz <drow@false.org>]

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