This is the mail archive of the
mailing list for the GDB project.
Re: Tracepoint enhancements
- From: Stan Shebs <stan at codesourcery dot com>
- To: Michael Snyder <msnyder at vmware dot com>
- Cc: Vladimir Prus <vladimir at codesourcery dot com>, "gdb at sources dot redhat dot com" <gdb at sources dot redhat dot com>
- Date: Tue, 04 Nov 2008 13:16:33 -0800
- Subject: Re: Tracepoint enhancements
- References: <490B630F.firstname.lastname@example.org> <490B6CEF.email@example.com> <firstname.lastname@example.org> <490F3F3C.email@example.com>
Michael Snyder wrote:
Vladimir Prus wrote:
I shall proceed on the assumption that we will make a tracepoint a kind
of breakpoint. This means we no longer need the special
enable/disable/delete commands. I think the original "trace" command
should remain as-is, and I'm also inclined to leave "actions" alone for
the moment, rather than try to merge with "commands"; while there could
be some useful unification, it seems like more of a sweeping change to
try to decide for every command, whether it could be part of a
tracepoint action or not. We get tracepoint conditions via "condition"
and "trace ... if" then. Not clear if "info tracepoints" should stick
around as a subset of "info breakpoints".
Michael Snyder wrote:
One more thing, only vaguely related...
I've thought that if we had the ability to attach an expression
(in pcode such as we use for tracepoints) to a conditional breakpoint,
we could have the conditional evaluation be done on the target
rather than by gdb, which would be a big performance win for
conditional breakpoints or watchpoints.
Yes. We want conditional tracepoints, and the condition would have to
on the target. And if breakpoints and tracepoints are unified, both
tracepoints will benefit.
Very good point. OK, you've convinced me.
Ignore counts vs passcounts still mystify me a bit. They seem
conceptually similar (modulo the sense inversion), but the documentation
for passcounts makes it seems as though one might expect all tracing and
all tracepoints to be disabled once a passcount is exceeded for any one
of them - and I see where that might be the desired behavior, vs the
per-breakpoint control of ignore counts.