All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Mike Frysinger <vapier.adi@gmail.com>
Cc: Roland McGrath <roland@redhat.com>,
	Christoph Hellwig <hch@lst.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	uclinux-dist-devel@blackfin.uclinux.org
Subject: Re: [PATCH 1/2] Blackfin: initial tracehook support
Date: Fri, 12 Feb 2010 16:24:04 +0100	[thread overview]
Message-ID: <20100212152404.GA9410@redhat.com> (raw)
In-Reply-To: <8bd0f97a1002112033m5805d4eco3add4d5625e71e9@mail.gmail.com>

On 02/11, Mike Frysinger wrote:
>
> On Thu, Feb 11, 2010 at 22:24, Roland McGrath wrote:
>
> > On some machines, single-step into a syscall instruction is no different
> > from other user instructions, so the normal SIGTRAP will come afterwards
> > anyway.
> >
> > On other machines, entering the kernel for the syscall instruction defeats
> > the normal user-mode effects of single-step being enabled.  In that event,
> > you want to call tracehook_report_syscall_exit() if single-step is enabled.
> > You must pass a nonzero second argument if your arch code is not going to
> > generate the normal SIGTRAP associated with having single-stepped into the
> > syscall instruction.
>
> so tracehook_report_syscall_exit() checking TIF_SINGLESTEP only makes
> sense when the arch doesnt support hardware single stepping in user
> mode ?  the Blackfin processor does support hardware single stepping
> (and we utilize it in Linux).

I'd like to know the answer too ;)

But, even if x86 supports hardware single stepping, it does check
TIF_SINGLESTEP and pass it to tracehook_report_syscall_exit(step).

Consider PTRACE_SINGLESTEP which follows the syscall-entry stop.
The tracee gets the trap before return to user-mode. Otherwise,
if we just return with X86_EFLAGS_TF, it gets the trap after the
next instruction after syscall insn. But I don't know whether
blackfin should follow this logic.

> also, in reading the kerneldocs for tracehook_report_syscall_exit(),
> it says "an attempted system call".  should system calls greater than
> NR_syscall (-ENOSYS) also get traced ?

I'd say yes, but let's wait for Roland's reply.

Oleg.


  reply	other threads:[~2010-02-12 15:25 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-02 18:57 [PATCH 1/14] move user_enable_single_step & co prototypes to linux/ptrace.h Christoph Hellwig
2010-02-02 18:58 ` [PATCH 2/14] alpha: use generic ptrace_resume code Christoph Hellwig
2010-02-03  4:35   ` Matt Turner
2010-02-02 18:58 ` [PATCH 3/14] arm: " Christoph Hellwig
2010-02-02 18:58 ` [PATCH 4/14] avr32: " Christoph Hellwig
2010-02-03  3:17   ` Haavard Skinnemoen
2010-02-03  8:36     ` Christoph Hellwig
2010-02-03 19:22       ` Oleg Nesterov
2010-02-03 19:28         ` Christoph Hellwig
2010-02-02 18:59 ` [PATCH 5/14] blackfin: " Christoph Hellwig
2010-02-02 20:29   ` Mike Frysinger
2010-02-03 19:36     ` Mike Frysinger
2010-02-03 19:42       ` Christoph Hellwig
2010-02-11  9:43   ` [PATCH 0/2] Blackfin: " Mike Frysinger
2010-02-11  9:43   ` [PATCH 1/2] Blackfin: initial tracehook support Mike Frysinger
2010-02-11 20:46     ` Roland McGrath
2010-02-11 23:54       ` Mike Frysinger
2010-02-12  3:24         ` Roland McGrath
2010-02-12  4:33           ` Mike Frysinger
2010-02-12 15:24             ` Oleg Nesterov [this message]
2010-02-12 20:44             ` Roland McGrath
2010-02-12 20:44               ` Roland McGrath
2010-02-13  9:41               ` Mike Frysinger
2010-02-15  7:36                 ` Mike Frysinger
2010-02-15 20:07                 ` Roland McGrath
2010-02-11  9:43   ` [PATCH 2/2] Blackfin: use generic ptrace_resume code Mike Frysinger
2010-02-11  9:43     ` Mike Frysinger
2010-02-11  9:43     ` Mike Frysinger
2010-02-02 18:59 ` [PATCH 6/14] h8300: " Christoph Hellwig
2010-02-02 18:59 ` [PATCH 7/14] m68knommu: " Christoph Hellwig
2010-02-03  6:54   ` Greg Ungerer
2010-02-02 18:59 ` [PATCH 8/14] microblaze: " Christoph Hellwig
2010-02-03 11:00   ` Michal Simek
2010-02-02 18:59 ` [PATCH 9/14] mips: " Christoph Hellwig
2010-02-02 19:19   ` Ralf Baechle
2010-02-02 19:00 ` [PATCH 10/14] um: " Christoph Hellwig
2010-02-02 19:00 ` [PATCH 11/14] xtensa: " Christoph Hellwig
2010-02-02 19:00 ` [PATCH 12/14] cris arch-v10: " Christoph Hellwig
2010-02-02 19:00 ` [PATCH, RFC 13/14] cris arch-v32: " Christoph Hellwig
2010-02-02 19:00 ` [PATCH, RFC 14/14] m32r: " Christoph Hellwig
2010-02-03  8:42 ` [PATCH 1/14] move user_enable_single_step & co prototypes to linux/ptrace.h Mike Frysinger
2010-02-03  8:42   ` Mike Frysinger
2010-02-03  8:56   ` Christoph Hellwig
2010-02-08 10:50 ` David Howells
2010-02-08 19:51 ` Roland McGrath
2010-02-10 22:03   ` Christoph Hellwig

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=20100212152404.GA9410@redhat.com \
    --to=oleg@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=hch@lst.de \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --cc=uclinux-dist-devel@blackfin.uclinux.org \
    --cc=vapier.adi@gmail.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.