This is the mail archive of the
mailing list for the GDB project.
Re: Tracepoint enhancements
- From: Vladimir Prus <vladimir at codesourcery dot com>
- To: Stan Shebs <stan at codesourcery dot com>
- Cc: Michael Snyder <msnyder at vmware dot com>, "gdb at sources dot redhat dot com" <gdb at sources dot redhat dot com>
- Date: Wed, 5 Nov 2008 10:13:31 +0300
- Subject: Re: Tracepoint enhancements
- References: <490B630F.email@example.com> <490F3F3C.firstname.lastname@example.org> <4910BBB1.email@example.com>
On Wednesday 05 November 2008 00:16:33 Stan Shebs wrote:
> Michael Snyder wrote:
> > Vladimir Prus wrote:
> >> 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
> >> be evaluated
> >> on the target. And if breakpoints and tracepoints are unified, both
> >> breakpoints and
> >> tracepoints will benefit.
> > Very good point. OK, you've convinced me.
> 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.
There's no need to do that. 'collect', 'while-stepping' and 'continue'
can be part of command set that is hardware-supported. Other commands do not.
>From MI standpoint, I disagree to having independent 'commands' and 'actions'
properties -- this makes no sense in the long run, and MI is not supposed to
be breaking behaviour at random, so we cannot implement 'actions' now, and
take it back later.
> 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.
Yeah, this is one bit that needs further design.