All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Pedro Alves <palves@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Roland McGrath <roland@hack.frob.com>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Tom Tromey <tromey@redhat.com>,
	Jan Kratochvil <jan.kratochvil@redhat.com>,
	Tejun Heo <tj@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC/PATCH] Implement new PTRACE_EVENT_SYSCALL_{ENTER,EXIT}
Date: Sun, 19 Jan 2014 16:29:22 +0100	[thread overview]
Message-ID: <20140119152922.GA13689@redhat.com> (raw)
In-Reply-To: <m3sisk4rfq.fsf@redhat.com>

On 01/19, Sergio Durigan Junior wrote:
>
> On Friday, January 10 2014, Oleg Nesterov wrote:
>
> > So suppose that gdb does ptrace(PTRACE_SINGLESTEP) and the tracee
> > executes the "syscall" insn. What it should report?
> [...]
> > But what should syscall-exit do? Should it still report SIGSEGV as
> > it currently does, or should it report _SYSCALL_EXIT instead (if
> > PTRACE_O_SYSCALL_EXIT of course), or should it report both?
>
> Both only if _SYSCALL_EXIT is set.  Otherwise, stick to the current
> behavior, I guess.

OK, both. In which order? Probably _EXIT first. But this looks a bit
strange. Suppose that the tracee reports _EXIT, then debugger does
ptrace(PTRACE_CONT), should the tracee report SIGTRAP?

SIGTRAP before _EXIT looks a bit strange too... Single-step trap should
be reported after insn, but we are still in syscall.

So perhaps _EXIT should win and do not report the step?

> Isn't it what my current patch does, by the way?

I forgot how this patch looks so I can be easily wrong, but iirc no.
Note that tracehook_report_syscall_exit() doesn't even call
ptrace_report_syscall() if step == T.

Btw, if you send v2, please CC Michael Kerrisk <mtk.manpages@gmail.com>.

Oleg.


  reply	other threads:[~2014-01-19 15:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-06 22:52 [RFC/PATCH] Implement new PTRACE_EVENT_SYSCALL_{ENTER,EXIT} Sergio Durigan Junior
2014-01-07 15:30 ` Oleg Nesterov
2014-01-07 16:37   ` Sergio Durigan Junior
2014-01-07 19:12     ` Oleg Nesterov
2014-01-09 18:49   ` Pedro Alves
2014-01-10 13:58     ` Oleg Nesterov
2014-01-19  2:48       ` Sergio Durigan Junior
2014-01-19 15:29         ` Oleg Nesterov [this message]
2014-05-14 18:49           ` Pedro Alves
2014-05-15 14:36             ` Denys Vlasenko
2014-05-16 10:30               ` Pedro Alves
2014-01-09 21:04   ` Roland McGrath
2014-01-19  2:39     ` Sergio Durigan Junior
2014-01-13 13:35 ` Denys Vlasenko
2014-01-19  2:29   ` Sergio Durigan Junior

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=20140119152922.GA13689@redhat.com \
    --to=oleg@redhat.com \
    --cc=dvlasenk@redhat.com \
    --cc=jan.kratochvil@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=palves@redhat.com \
    --cc=roland@hack.frob.com \
    --cc=sergiodj@redhat.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=tromey@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 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.