Dave Nomura <dcnltc@us.ibm.com> writes:
[...]
Frank suggested the following a few months ago:
probe process(PID_OR_NAME).itrace if (condition) { }
probe process(PID_OR_NAME).function("NAME") { condition = 1 }
probe process(PID_OR_NAME).function("NAME").return { condition = 0 }
Please note that we still lack a complete ("optimized") implementation
of this syntax. It gets checked, but is emitted as an ordinary
nested conditional:
probe FOO if (condition) { }
=> probe FOO { if (condition) { } }
That's because each type of probe point ("derived_probe_group") would
need to learn how to activate and deactivate its probes on the fly,
something I've started to work on but haven't yet finished.
But this should be just an optimization. For your purposes, make the
".itrace" probe point simply turn on instruction-by-instruction
tracing, regardless of conditions etc.
So, the idea is that the instruction tracing handler that will get
called by the utrace report_signal handler (when a single-step trap
occurs) and the handler body will comprise: "if (condition) {
.... }"
Right, for now.
1) the task_finder callback gets called with register_p=1: it
initializes my instruction tracing stuff, sets up a function pointer
to the generated probe corresponding to "if(condition) { .... }"
2) the two probes to set and unset the condition variable get called
3) the utrace report_signal handler for the single-step trap gets
called many times, as expected. it calls the function pointer set
up in 1) but it appears that I never get past the generated "if
(condition)" code because I don't get any _stp_printf output.
That sounds like it should work. Do you get your trace data when
the condition is taken away altogether?
- FChE