From: Dave Nomura <dcnltc@us.ibm.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Maynard Johnson <mpjohn@us.ibm.com>,
systemtap@sourceware.org,
Maynard Johnson <mpjohn@us.ibm.com>,
James Keniston <kenistoj@us.ibm.com>
Subject: Re: proposed instruction trace support in SystemTap
Date: Thu, 23 Aug 2007 22:10:00 -0000 [thread overview]
Message-ID: <46CDF9DD.9000503@us.ibm.com> (raw)
In-Reply-To: <46C8A82C.1000204@us.ibm.com>
From a conversation with Paul Mackerras I recently learned that
__debugger_sstep() is the PPC trap handler pointer used only for kernel
debugging, and its use is based on only one kernel debugger active at a
time. Although I think a kernel API could be created to coordinate use
of this function pointer, I don't think one exists. It would probably
be prudent to put restrictions on instruction tracing of kernel code in
the SystemTap-itrace feature.
Although ptrace() probably is not suitable for instruction tracing of
user code, if for no other reason that performance issues, I have been
looking into some of the documentation of utrace, and am wondering if it
might be suitable.
I
Dave Nomura wrote:
> 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
>>
>>
>
>
next prev parent reply other threads:[~2007-08-23 21:20 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
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 ` Dave Nomura [this message]
2007-07-06 21:39 ` proposed instruction trace support in SystemTap 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=46CDF9DD.9000503@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).