From: Dave Nomura <dcnltc@us.ibm.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: systemtap@sourceware.org, Maynard Johnson <mpjohn@us.ibm.com>,
James Keniston <kenistoj@us.ibm.com>
Subject: Re: proposed instruction trace support in SystemTap
Date: Mon, 20 Aug 2007 00:34:00 -0000 [thread overview]
Message-ID: <46C8A82C.1000204@us.ibm.com> (raw)
In-Reply-To: <y0m3azwgw6u.fsf@ton.toronto.redhat.com>
I've been looking into the kernel API for handling single stepping and
haven't really found anything. ptrace() is used by gdb but it's usage
model might be overly restrictive for what we want: we would have to
have a parent process then uses ptrace() to trace it's children.
ptrace() also does not trace into the kernel which is an ITRACE requirement.
I think the requirement of tracing into the kernel is only needed in
some scenarios and may only be needed for the ITRACE application of
SystemTap instruction tracing. In its most general form Perfomance
Inspector ITRACE allows tracing into the kernel and tracing of a whole
range of processes. Due to these requirements it places usage
constraints on the user that requires exclusive access ot a machine. In
the more common SystemTap instruction tracing scenario only a single
process is being traced, and only user code is traced maybe it would be
approriate to use ptrace() to do the single stepping.
It has already been suggested that we have different APIs for ITRACE vs.
simpler (non-kernel tracing) instruction tracing modes so it might be a
simple matter of telling the SystemTap translator what kind of trap
handler to generate (or referencd from the runtime stap scripts). In
the non-kernel-tracing-single-process scenario just the normal process
switch management of registers will handle restoring the single step
trap bit, or if ptrace() (or possibly utrace()).
The ITRACE-kernel-tracing scenario might require similar usage
restrictions as PI ITRACE, and we simply would require that you aren't
using other kernel debuggers (xmon, kgdb,...) while trying to do an
ITRACE to avoid conflict over the kernel resources needed for
instruction tracing. Alternatively, a kernel API (if it doesn't
already exist) for handling these kernel resources could be created. I
have heard that xmon and kgdb both use the __debugger_sstep() trap
handler pointer.
Frank Ch. Eigler wrote:
>
>> [...] There is basically one single instruction trap handler that
>> the stap translator will generate with logic to figure out what
>> handler code to run [...]
>>
>
> The "existing kernel API" is the key issue here. How exactly does one
> activate single-stepping traps on each of the interesting
> architectures, and on multiple different kernel generations (RHEL)?
> How does one hook into the handling system correctly (avoiding
> interference to other consumers of trap data like gdb, uprobes)?
>
> These questions need answers in order for systemtap to generate code
> to implement this.
>
>
>
> - FChE
>
>
--
Dave Nomura
LTC Linux Power Toolchain
next prev parent reply other threads:[~2007-08-19 20:29 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-02 23:01 Dave Nomura
2007-07-05 19:37 ` Frank Ch. Eigler
2007-07-06 12:46 ` grundy
2007-07-06 14:59 ` Frank Ch. Eigler
2007-07-06 21:43 ` Maynard Johnson
2007-07-07 1:58 ` Frank Ch. Eigler
2007-07-10 15:47 ` Maynard Johnson
2007-07-10 14:12 ` Dave Nomura
2007-07-10 14:39 ` Frank Ch. Eigler
2007-07-10 20:57 ` Maynard Johnson
2007-07-10 22:45 ` Jim Keniston
2007-07-11 4:31 ` Ananth N Mavinakayanahalli
2007-08-20 0:34 ` Dave Nomura [this message]
2007-08-20 0:37 ` Roland McGrath
2007-08-25 11:34 ` Dave Nomura
2007-08-29 14:57 ` Frank Ch. Eigler
2007-08-30 5:43 ` kernel API for in-kernel single stepping Dave Nomura
2007-08-30 13:05 ` Paul Mackerras
2007-09-04 3:05 ` Frank Ch. Eigler
2007-09-05 5:02 ` Dave Nomura
2007-08-29 15:40 ` proposed instruction trace support in SystemTap Dave Nomura
2007-08-29 16:25 ` Frank Ch. Eigler
2007-09-06 2:57 ` using utrace for instruction tracing Dave Nomura
2007-09-06 14:05 ` Jim Keniston
2007-09-06 18:28 ` Dave Nomura
2007-08-23 22:10 ` proposed instruction trace support in SystemTap Dave Nomura
2007-07-06 21:39 ` Maynard Johnson
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=46C8A82C.1000204@us.ibm.com \
--to=dcnltc@us.ibm.com \
--cc=fche@redhat.com \
--cc=kenistoj@us.ibm.com \
--cc=mpjohn@us.ibm.com \
--cc=systemtap@sourceware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).