public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Masami Hiramatsu <mhiramat@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
	LKML <linux-kernel@vger.kernel.org>,
	systemtap-ml <systemtap@sources.redhat.com>
Subject: Re: [RFC][PATCH -tip 0/9] tracing: kprobe-based event tracer
Date: Fri, 20 Mar 2009 09:45:44 +0100	[thread overview]
Message-ID: <20090320084544.GA16021@elte.hu> (raw)
In-Reply-To: <49C30EA5.5040707@redhat.com>


* Masami Hiramatsu <mhiramat@redhat.com> wrote:

> Frederic Weisbecker wrote:
> > On Thu, Mar 19, 2009 at 05:09:56PM -0400, Masami Hiramatsu wrote:
> >> Hi,
> >>
> >> This is a series of patches which introduce a proof-of concept of
> >> kprobe-based event tracer to ftrace. I think that we could port some
> >> tracing features from systemtap on this vehicle.
> >> This can be applied on the linux-2.6-tip tree.
> >>
> >> This patchset includes following changes:
> >> - Add kprobe-tracer plugin
> >> - Add kernel_trap_sp() on x86, ia64, power, s390, arm which are
> >>   ported from systemtap runtime.
> >> - Add module_*probe api for repawning/removing kprobes when target
> >>   module is coming/going.
> >>
> >> It's still not unclear that the last module_*probe would better be
> >> provided as APIs or just embed it in trace_kprobe.c.
> >>
> >> Future items:
> >> - Use binary print.
> >> - Add kernel_trap_sp() on other archs.
> >> - Support symbol-based memory fetching (for global variables)
> >> - Support primitive types(long, ulong, int, uint, etc) for args.
> >> - Support indirect memory fetch from register etc.
> >> - Check insertion point safety by using instruction decoder.
> >>
> >> kprobe-based event tracer
> >> ---------------------------
> >>
> >> This tracer is similar to the events tracer which is based on Tracepoint
> >> infrastructure. Instead of Tracepoint, this tracer is based on kprobes(kprobe
> >> and kretprobe). It probes anywhere where kprobes can probe(this means, all
> >> functions body except for __kprobes functions).
> >>
> >> Unlike the function tracer, this tracer can probe instructions inside of
> >> kernel functions. It allows you to check which instruction has been executed.
> >>
> >> Unlike the Tracepoint based events tracer, this tracer can add new probe points
> >> on the fly.
> >>
> >> Similar to the events tracer, this tracer doesn't need to be activated via
> >> current_tracer, instead of that, just set probe points via
> >> /debug/tracing/kprobe_probes.
> >>
> >> Synopsis of kprobe_probes:
> >>   p SYMBOL[+offs|-offs]|MEMADDR [FETCHARGS]     : set a probe
> > 
> > 
> > Ahh, I see this is not only about parameters but also about very low level
> > debugging, such as registers dumps.
> > 
> > This is very powerful.
> 
> Please take care, don't shot your foot :)
> This tracer doesn't have a safety lever(e.g. instruction boundary checker) yet.
> So, currently, we need to use this with objdump -d.

Would be really nice to have this in the future. We could reuse 
existing opcode decoders in the x86 code for that i think. KVM has 
probably the most potent one.

Cool stuff!

	Ingo

  reply	other threads:[~2009-03-20  8:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-19 21:09 [RFC][PATCH -tip 0/9] tracing: kprobe-based event tracer Masami Hiramatsu
2009-03-20  0:10 ` Steven Rostedt
2009-03-20  3:05   ` Masami Hiramatsu
2009-03-20  0:24 ` Frederic Weisbecker
2009-03-20  3:33   ` Masami Hiramatsu
2009-03-20  8:45     ` Ingo Molnar [this message]
2009-03-20  9:00       ` Ananth N Mavinakayanahalli

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=20090320084544.GA16021@elte.hu \
    --to=mingo@elte.hu \
    --cc=ananth@in.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=systemtap@sources.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox