Hi -
Did you have any comments on the actual content of my patch?
Yes, it was a good proof-of-concept of using utrace as the
instruction-stepping infrastructure.
Did you want to resolve the translator syntax changes to support
instruction tracing first?
I believe we do need proper translator-side support for this feature,
beyond what the tapset-only prototype provides. We need end-user
scripts using itrace should not to have to use embedded-c code, and
we need the implementation to be robust (i.e., not require users
to match each "turn on itrace for pid PID" with "... off ...".
The first pair of probe point extensions listed in
http://tinyurl.com/2e77sb:
probe process(PID).itrace { }
probe process(PID).btrace { } # block trace
should be reasonably easy to implement. The embedded-C code currently
in the tapset would become some mixture of code inlined by the
translator, or else copied into the runtime. Adding dynamic
designation of target processes would be a small followup step.
Most of the discussion regarding the translator syntax changes was
beyond my understanding of SystemTap. [...]
We did go a bit far afield from the initial question, sorry about that.
- FChE