proposed instruction trace support in SystemTap

[Dave Nomura <dcnltc at us dot ibm dot com>]

PROPOSED INSTRUCTION TRACING INTEGRATION INTO SYSTEMTAP
A user would write a stap script that identified where to turn on 
instruction tracing and where to turn it off.  The stap script could be 
invoked via: stap <user_script>.stp -b -M -c "<some program>" -o 
<trace_data>
to allow the stap script to access the pid to trace, although other 
usage modes are also possible.  Some enhancements to the stap translator 
are suggested below to support instruction tracing.

SINGLE_STEP/BRANCH TRAP HANDLER
The user's stap script would also need to define an instruction trace 
handler and insert their own body for the handler.  This might look like:
probe single_step label("single_step handler 1")
{
       <do whatever you want for each single stepped instruction>
       itrace_output();        // write itrace binary output
}

probe branch_step label("branch handler 1")
{
       <do whatever you want for each branch instruction>
       itrace_output();        // write itrace binary output
}

where "label" is an language extension to attach a name to a instruction 
trace probe that would allow you to have different instruction trace 
handlers for different instruction trace probes.  There would only be 
one single_step trap handler but it would use the label to decide which 
code to execute from the user's stap script.

The itrace_output() is a function that produces the raw trace data that 
could then be post processed for consumption by various performance 
analysis tools but the user could do something as simple as printing out 
the PC value.  It might be nice if there was some way to name the relay 
streams so that they aren't intermingled.  Maybe something analogous to 
the stream parameter to fprintf.

The SystemTap translator would generate calls to target dependent code 
to implement single instruction or branch trapping.  This is done a 
variety of ways on different architectures, but generally involves 
setting a bit in a system register to enable single instruction/branch 
trapping.


TURNING ON/OFF TRACING
The user's stap script would turn on/off instruction tracing by creating 
a uprobe containing a call to a SystemTap itrace tapset function for 
turning on/off instruction tracing.  I don't know what SystemTap's 
uprobe interface will look like but it might be something like:
probe process(target()).function(
"function_to_trace")
{
       itrace_on_pid("single step handler 1", pid())
}

probe process(target()).function("function_to_trace").return
{
       itrace_off(pid())
}

Note:
- instruction tracing enabled for a parent process id will enable 
tracing for all of its children (threads). Since uprobes are on a 
per-process basis rather than per-thread, instruction tracing would be 
constrained to the same semantics, although it would be possible for a 
user to write their single step handler to treat some threads individually.
- The "single step handler 1" parameter is the label attached to the 
instruction trace handler above to allow one to have different handlers 
for different instruction trace probes.

INITIALIZATION/CLEANUP
Initialization/cleanup of the instruction tracing feature could be done 
by insertion of a call to an itrace initialilzation/cleanup routine in 
the user's begin/end probes.

probe begin
{
       itrace_init(<some params>)
}

probe end
{
       itrace_cleanup()
}