From: Daniel Jacobowitz <dan@debian.org>
To: Roland McGrath <roland@redhat.com>
Cc: Davide Libenzi <davidel@xmailserver.org>,
Andrew Morton <akpm@osdl.org>, Linus Torvalds <torvalds@osdl.org>,
mingo@redhat.com, cagney@redhat.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] x86 single-step (TF) vs system calls & traps
Date: Thu, 1 Jul 2004 16:34:56 -0400 [thread overview]
Message-ID: <20040701203455.GA22888@nevyn.them.org> (raw)
In-Reply-To: <200407010747.i617lxIB019894@magilla.sf.frob.com>
On Thu, Jul 01, 2004 at 12:47:59AM -0700, Roland McGrath wrote:
> > Roland, I don't think (pretty sure actually ;) we can handle the case
> > where TF is set from userspace and, at the same time, the user uses
> > PTRACE_SINGLESTEP.
>
> I don't know where you pulled the notion of that case from. I certainly
> never mentioned it. When I raised the case of user-mode setting of TF, I
> was quite clear that it's a case when ptrace is not involved.
>
> > The PTRACE_SINGLESTEP gives you the SYSGOOD behaviour, if you set it. And
> > sends a SIGTRAP notification to the ptrace'ing parent process.
>
> Like I said before, that is a change in the behavior. Since its inception,
> SYSGOOD has meant exactly and only that when you use PTRACE_SYSCALL you
> will get a different notification for a syscall-tracing stop than other
> sources of SIGTRAP that may arise during execution of user code between
> system calls. At no time ever before, has it been possible to get the
> SIGTRAP|0x80 wait result when you had not just called PTRACE_SYSCALL.
> After your change, calling PTRACE_SINGLESTEP can now produce that result.
> I don't think that change is a good thing.
>
> As the originator of the SYSGOOD option, Dan might have a comment about this.
I am not the originator of PTRACE_O_TRACESYSGOOD, I just had the bad
luck to touch it.
I think reporting the system call using 0x80|SIGTRAP when you
PTRACE_SINGLESTEP over the trap instruction makes excellent good sense.
--
Daniel Jacobowitz
next prev parent reply other threads:[~2004-07-01 20:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-06-29 1:55 [RFC PATCH] x86 single-step (TF) vs system calls & traps Roland McGrath
2004-06-29 2:05 ` Davide Libenzi
2004-06-29 3:42 ` Linus Torvalds
2004-06-29 3:46 ` Roland McGrath
2004-06-29 3:55 ` Linus Torvalds
2004-06-29 4:15 ` Andrew Morton
2004-06-29 4:37 ` Roland McGrath
2004-06-29 7:00 ` Davide Libenzi
2004-07-01 7:47 ` Roland McGrath
2004-07-01 15:14 ` Davide Libenzi
2004-07-01 20:24 ` Roland McGrath
2004-07-01 21:47 ` Davide Libenzi
2004-07-01 20:34 ` Daniel Jacobowitz [this message]
2004-07-01 21:59 ` Roland McGrath
2004-07-02 4:22 ` Daniel Jacobowitz
2004-06-29 4:32 ` Roland McGrath
2004-06-29 5:15 ` Linus Torvalds
2004-07-01 8:09 ` Roland McGrath
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=20040701203455.GA22888@nevyn.them.org \
--to=dan@debian.org \
--cc=akpm@osdl.org \
--cc=cagney@redhat.com \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=roland@redhat.com \
--cc=torvalds@osdl.org \
/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.