Re: user instruction tracing patch?

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

I am finally at a point where I can start looking at the translator 
changes to support instruction tracing.  There was a discussion of the 
pros/cons of your proposed support, only about half of which I could 
follow between Jim Keniston, Roland McGrath, and yourself.  Did that 
discussion result in any modifications to your proposal below?

I have a few other questions (inline below).
Frank Ch. Eigler wrote:
> So, here's a possibly better way.  The script-side interface
> would look like:
>
>   probe process(PID).itrace { }
>   probe process(PID).btrace { }   # block trace
>   probe process(NAME).itrace { }
>   probe process(NAME).btrace { }
>
> The name variant could be implemented by a startup-time mapping of
> execname->pid.  There's probably a utrace hook that will let us be
> notified of execs, so that we can keep the mapping up-to-date during
> run time.
>   
So the NAME variant would be like "probe process("/usr/bin/vi").btrace 
and this would get mapped to all instances of "/usr/bin/vi" processes at 
startup time, and we would use a utrace hook to add in probes for newly 
created instances of vi?

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") ?)
>
> It's also a bit risky to expose the on/off functionality as explicit
> functions (though an end-user script or tapset could be more assured
> of proper cleanup using "probe end,error {...}".)  But of course it's
> desirable to turn things on/off dynamically, so how?  A special case
> of bug #4935 might be the ticket, once that is complete:
>
>   probe process(PID).itrace if (condition) { }
>   probe process(PID).function("NAME") { condition = 1 }
>   probe process(PID).function("NAME").return { condition = 0 }
>
>   
So, rather than have the user explicitly call routines to turn on/off 
tracing for a PID, you set this condition variable. After talking with 
Jim Keniston, my understanding is that, in this example, the fact that 
there is an "if (condition)" on the it .itrace probe the translator will 
be looking for any modifications to "condition" as a signal to insert a 
call to turn on/off instruction tracing.
The user must be aware that "condition = 1" has the side effect of 
turning on instruction tracing. He would have to avoid things like:
      condition = 0;  // default
      if (criteria1) then
         condtion = 1;
     endif
Would modification of "condition" have this side-effect anywhere in 
their tapset, or only in the context of a "probe process..." probe?

My understanding is that this if(condition) idea is not specific to 
instruction tracing and there is some ongoing effort to implement it.  
How is that going? 

Is it premature for me to start on instruction tracing support until the 
"if(expr)" support is complete?



--
Dave Nomura
LTC Linux Power Toolchain