This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Conditional tracepoints
Tom Tromey wrote:
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" == Stan Shebs <firstname.lastname@example.org> 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.
Now I'm wondering if we could use agent expressions for conditional
breakpoints somehow :-)
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
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?
Stan> + struct agent_expr *I agree. :-)
Stan> + gen_eval_for_expr (CORE_ADDR scope, struct expression *expr)
Could use a header comment.
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> 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.