This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: user instruction tracing patch?
- From: "Frank Ch. Eigler" <fche at redhat dot com>
- To: Dave Nomura <dcnltc at us dot ibm dot com>
- Cc: systemtap at sourceware dot org
- Date: Mon, 17 Mar 2008 11:14:58 -0400
- Subject: Re: user instruction tracing patch?
- References: <4739E5C2.80206@us.ibm.com> <y0mzlxg4iw2.fsf@ton.toronto.redhat.com> <47D582BB.2060209@us.ibm.com>
Hi, Dave -
> I am finally at a point where I can start looking at the translator
> changes to support instruction tracing. [...]
> > probe process(PID).itrace { }
> > probe process(PID).btrace { } # block trace
This is the only variant you need to worry about, as
> > probe process(NAME).itrace { }
> > probe process(NAME).btrace { }
this stuff will come later, based on process-lifetime-tracking code
being currently built by dsmith.
> [...]
> These probes simply establish that instruction tracing, either itrace,
> or btrace, is requested for specific processes, and associating a
> generated handler corresponding to the { ... } part.
>
> >Since utrace will provide the pt_regs structure, the probe handler
> >bodies will be able to call e.g. backtrace(), probefunc(), and really
> >should have some structured access to the registers (a new tapset
> >function like register:long ("name") ?)
The tapset extensions for context access are very similar to the needs
of symbol-only probing being worked on jkenisto.
> > probe process(PID).itrace if (condition) { }
> > probe process(PID).function("NAME") { condition = 1 }
> > probe process(PID).function("NAME").return { condition = 0 }
This part will already work.
FChE