[PATCH -tip 0/6 V4] tracing: kprobe-based event tracer
Ingo Molnar
mingo@elte.hu
Fri Apr 3 11:27:00 GMT 2009
* Masami Hiramatsu <mhiramat@redhat.com> wrote:
> Hi,
>
> Here are the patches of kprobe-based event tracer for x86, version 4.
>
> This version supports only x86(-32/-64) (If someone is interested in
> porting this to other architectures, he just needs to port
> kprobes/kretprobes and ptrace enhancement[PATCH 2/6]).
>
> I added x86 insn decoder on this version. It might be better
> integrated with KVM's decoder, and kprobes x86 code should be
> rewritten with it.
>
>
> This can be applied on the linux-2.6-tip tree.
>
> This patchset includes following changes:
> - Fix kernel_trap_sp() on x86 according to systemtap runtime. [1/6]
> - Add arch-dep register and stack fetching functions [2/6]
> - Add x86 instruction decoder [3/6]
> - Check insertion point safety in kprobe [4/6]
> - Add kprobe-tracer plugin [5/6]
> - Support fetching various status (register/stack/memory/etc.) [6/6]
ok, the structure and concept looks quite good now, really nice!
I'm wondering about something i suggested many moons ago: to look
into the KVM decoder+emulator (arch/x86/kvm/x86_emulate.c).
I remember there were some issues with that (one problem being that
the KVM decoder is a special-purpose thing covering specific range
of execution environments - not a near-full integer-ops decoder like
the one we are aiming for here) - are there any other fundamental
problems beyond 'it has to be done' ?
Conceptually we want just a single piece of decoder logic in
arch/x86/. If the KVM folks are cool with it we could factor out the
KVM one into arch/x86/lib/. But ... if there are compelling reasons
to leave the KVM one alone in its limited environment we can do that
too.
Avi, Peter, what's your take on this?
Ingo
More information about the Systemtap
mailing list