conditional probes

[Dave Nomura]

I think the problem is that from within the utrace .report_signal 
handler I want to call the function that corresponds to "if (condition) 
{ ... }" which is represented as say probe_1064(struct context *), but I 
don't know where I would find the "struct context *" argument that the 
probe_1064() requires.  I couldn't even find any calls to any of the 
probe_*() routines to get an idea of how the "struct context *" argument 
is created.

Any suggestions?

Frank Ch. Eigler wrote:
> 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
>   


-- 
Dave Nomura
LTC Linux Power Toolchain