This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: proposed instruction trace support in SystemTap
- From: Dave Nomura <dcnltc at us dot ibm dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: "Frank Ch. Eigler" <fche at redhat dot com>, systemtap at sourceware dot org, Maynard Johnson <mpjohn at us dot ibm dot com>
- Date: Wed, 29 Aug 2007 08:28:55 -0700
- Subject: Re: proposed instruction trace support in SystemTap
- Organization: LTC Power Linux Toolchain
- References: <20070819204722.E3A9A4D058C@magilla.localdomain>
- Reply-to: dcnltc at us dot ibm dot com
Would the performance of utrace be acceptable for doing instruction
tracing? It sounds like a lot of the signal overhead of ptrace is
eliminated.
Would utrace only be useful for user-mode stepping, or could it somehow
handle the in-kernel case?
Roland McGrath wrote:
For user-mode stepping (all you can do via ptrace), this is what the utrace
in-kernel APIs give you. The in-kernel case has enough different issues
that I think it's appropriate to consider it an entirely separate case.
For that, kprobes already has its fingers in this area of machine-specific
code. It might make most sense for in-kernel stepping to be an extension
of the kprobes code. OTOH, with the hw_breakpoint (nee kwatch) work by
Alan Stern <stern@rowland.harvard.edu> we have a second in-kernel case that
(on some machines) wants to get involved with single-stepping. Perhaps it
makes sense to consolidate the efforts on some shared low-level part that
deals with the stepping part.
Or there may not be enough to be done there
that anything beyond current machine-specific calls and trap notifiers are
really required. (Off hand I think at least some kind of coordination will
be required to avoid these three things stepping on each other's toes.)
Thanks,
Roland
--
Dave Nomura
LTC Linux Power Toolchain