From: Daniel Jacobowitz <dan@debian.org>
To: Roland McGrath <roland@redhat.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: Re: Signal/gdb oddity in 2.5.61
Date: Sun, 16 Feb 2003 22:02:25 -0500 [thread overview]
Message-ID: <20030217030225.GA9917@nevyn.them.org> (raw)
In-Reply-To: <200302170100.h1H10aQ28610@magilla.sf.frob.com>
On Sun, Feb 16, 2003 at 05:00:36PM -0800, Roland McGrath wrote:
> > That said, I've still got two issues with your change. For one thing,
> > the version of GDB that Russell was running, you'll note, was 5.0. A
> > lot of people haven't upgraded GDB in years, and have some dispute with
> > the present version that means they don't want to upgrade. I've only
> > just stopped seeing people using 4.18. In conversation with Russell
> > I've already encountered another reason he doesn't want to upgrade.
>
> Anyone who wants to use an old gdb with a new kernel can use "handle
> SIGSTOP nopass". Is that a real imposition? Anyway, aside from the test
> suite, it only affects gdb users in a way that may confuse them for a few
> seconds but doesn't prevent them from debugging normally.
>
> > And I'm also concerned that other programs may use it.
>
> Other programs may use PTRACE_CONT with SIGSTOP and expect it to act like
> PTRACE_CONT with 0? It's certainly possible. But since the quirk with
> SIGSTOP was so counterintuitive to begin with, it seems unlikely to me that
> someone would have expected that behavior in particular. Some programs
> like strace are written to treat all signals the same and pass them through
> to PTRACE_CONT (actually PTRACE_SYSCALL); they will now cause an endless
> stream of SIGSTOP stops until someone uses SIGCONT, instead of swallowing
> the SIGSTOP--now they do for SIGSTOP what they've always done for SIGTSTP
> et al.
I think I'm convinced. Sorry for wasting your time. If it comes up we
can put it on a GDB FAQ somewhere.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-02-17 2:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44.0302161117370.2874-100000@home.transmeta.com>
2003-02-16 22:28 ` Signal/gdb oddity in 2.5.61 Roland McGrath
2003-02-16 23:27 ` Daniel Jacobowitz
2003-02-16 23:44 ` Linus Torvalds
2003-02-17 1:00 ` Roland McGrath
2003-02-17 2:34 ` Jeff Dike
2003-02-17 3:02 ` Daniel Jacobowitz [this message]
2003-02-16 19:15 Russell King
2003-02-16 22:10 ` Daniel Jacobowitz
2003-02-16 22:14 ` Russell King
2003-02-16 22:21 ` Daniel Jacobowitz
2003-02-16 22:28 ` Russell King
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=20030217030225.GA9917@nevyn.them.org \
--to=dan@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=torvalds@transmeta.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.