This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Conditional tracepoints

Tom Tromey wrote:
"Stan" == Stan Shebs <> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]