Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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	[thread overview]
Message-ID: <200405102140.i4ALe13A001092@elgar.kettenis.dyndns.org> (raw)
In-Reply-To: <409FF3D7.5000106@gnu.org>

   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


  reply	other threads:[~2004-05-11  5:15 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-05-07  1:19 Andrew Cagney
2004-05-07  0:48 ` Roland McGrath
2004-05-07  1:31   ` Daniel Jacobowitz
2004-05-10 21:39     ` Andrew Cagney
2004-05-07  1:19 ` Andrew Cagney
2004-05-07  1:25   ` Daniel Jacobowitz
2004-05-10 21:27     ` Andrew Cagney
2004-05-11  5:15       ` Mark Kettenis [this message]
2004-05-11 14:49         ` Andrew Cagney
2004-05-11 14:53         ` Daniel Jacobowitz
     [not found]           ` <40A0FFB1.8030407@gnu.org>
2004-05-11 17:26             ` Daniel Jacobowitz
2004-05-12  0:28               ` Andrew Cagney
2004-05-15 20:58                 ` Mark Kettenis
2004-05-17 17:14                   ` Revamp sniffer; Was: " Andrew Cagney
2004-05-25 22:55                     ` Andrew Cagney
2004-06-11 17:32                       ` Andrew Cagney
2004-06-15 20:17                         ` Andrew Cagney
2004-06-16 23:07                           ` Roland McGrath
2004-06-24 18:10                             ` Andrew Cagney
2004-06-24 20:59                               ` Roland McGrath
2004-06-24 21:20                                 ` Mark Kettenis
2004-05-17 20:10 ` Andrew Cagney
     [not found]   ` <20040517131914.332fa347@saguaro>
2004-05-18  5:59     ` Eli Zaretskii
2004-05-18 20:09       ` Andrew Cagney
2004-05-19  5:50         ` Eli Zaretskii
2004-05-19 14:47           ` Andrew Cagney
2004-05-19 21:10             ` Eli Zaretskii
2004-05-20  5:33               ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200405102140.i4ALe13A001092@elgar.kettenis.dyndns.org \
    --to=kettenis@chello.nl \
    --cc=cagney@gnu.org \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=roland@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox