Re: [PATCH] Conditional tracepoints

[Stan Shebs <stan@codesourcery.com>]

Tom Tromey wrote:
>>>>>> "Stan" == Stan Shebs <stan@codesourcery.com> writes:
>>>>>>             
>
> Stan> This patch adds conditional tracepoints.  Tracepoint conditions work
> Stan> by being compiled into agent expressions that actually evaluate on the
> Stan> spot in the target, rather than collecting blocks of trace data.
>
> Very cool.
>
> Now I'm wondering if we could use agent expressions for conditional
> breakpoints somehow :-)
>   
Certainly jimb didn't want to restrict agent expressions to just 
tracepoints. The messy part would be getting from trap hit to evaluator, 
since the usual native debugging arrangement gives control back to GDB 
right away. I suppose there is still a performance win if GDB does the 
effective equivalent of an inferior call to the evaluator after the trap 
is hit, 2-3 roundtrips is still better than 10-100.
> Stan> As usual for tracepoints, GDB proper doesn't have to do much,
> Stan> and most of the code here revolves around checking for the
> Stan> "ConditionalTracepoints" feature, so as to maintain
> Stan> compatibility with the two(?) existing tracepoint
> Stan> implementations out there.
>
> Are either of these free software?
>   
Yes, I was thinking of Nicholas McGuire's work, and Jim's Trac project. 
Probably no one would notice in real life, but I couldn't quite bring 
myself to make incompatible protocol changes without adding a feature 
test...
> Stan> + 
> Stan> + struct agent_expr *
> Stan> + gen_eval_for_expr (CORE_ADDR scope, struct expression *expr)
>
> Could use a header comment.
>   
I agree. :-)
> Stan> Index: tracepoint.c
> [...]
> Stan> + extern int remote_supports_cond_tracepoints (void);
>
> This seems fishy to me.
>
> At the very least I think this should be in a header, not in the .c
> file.  But... other cases like this seem to be expressed via target
> methods, not as direct calls into remote.c.
>   
I beg a little indulgence for the moment - the massive target vector 
change is coming in about ten patches or so. Since it touches everything 
in tracepoint.c, patches from before that change wouldn't even start to 
apply, so I'm recapitulating the order in which I wrote the pieces.  In 
the process, we'll be seeing lots of places where the tracepoint code 
knows too much about the remote protocol code.

Stan