This is the mail archive of the
mailing list for the GDB project.
Re: Tracepoint enhancements
- From: Jeremy Bennett <jeremy dot bennett at embecosm dot com>
- To: gdb at sourceware dot org
- Date: Mon, 03 Nov 2008 09:11:29 +0000
- Subject: Re: Tracepoint enhancements
- References: <490B630F.firstname.lastname@example.org>
- Reply-to: jeremy dot bennett at embecosm dot com
On Fri, 2008-10-31 at 12:57 -0700, Stan Shebs wrote:
> There is some interest in pumping up GDB's tracepoint capabilities, in
> particular to make it more suitable for cross-debugging a target with
> serious performance constraints. While a lot of the detail is centered
> around making a faster stub and other low-level tweaks, we are going to
> do MI for tracing finally, plus it's an opportunity to review the
> existing trace commands and consider what interface changes are
> desirable. In particular, we will want to think about how tracing should
> interoperate with non-stop debugging and multi-process.
> So the first question that comes to my mind is: how many people are
> actually using the trace commands right now? If they're not being much
> used, then we have more flexibility about making user-visible changes.
I've been working on the OpenRISC 1000, which has hardware trace
support. No one has yet complained that I dropped trace functionality
from GDB 6.8 for OpenRISC, so I guess it's not currently in use by that
> One possible change to consider is to merge tracepoint setting into
> breakpoint setting. Among other benefits would be a single numbering
> scheme for breakpoints and tracepoints, plus we will be able to share
> some machinery and make things more consistent.
I'd strongly encourage a uniform reference scheme. Not necessarily just
numbers - something richer may be needed in complex environments. This
should work for ANY target covering breakpoints, watchpoints,
catchpoints, tracepoints etc.
This ties in with your work on multiprocess/multiprogram support. A
debugging target might be a complex SoC with multiple heterogenous
processor cores together with peripherals having substantial state and
processing power. Eventually GDB should be able to handle all of this
This will require a standard way of addressing ANY part of such a target
- not just within one processor - and turning it into a unique reference
for GDB. For example I could specify a watchpoint on internal state of a
peripheral, asking for execution to stop (on some or all
threads/processes/processors/peripherals) if that internal state
At some stage a general way of linking the reference to a complex
specification will be needed. I am not sure that "condition" and
"break ... if" are sufficient. They certainly will need to reference
multiple threads and target functional units.
> A bigger change would be to introduce a general notion of execution
> history, which could subsume fork checkpoints and trace snapshots, maybe
> tie into some versions of reverse debugging as well.
Which also requires a way of specifying what execution you are talking
about. A uniform way of addressing potentially hundreds of thousands of
threads of control individually and in arbitrary groupings.
Some of this is a long way in the future, but I hope it provides a
context for thinking about changes to GDB today.
> What else should we be thinking about doing?
> (There are of course all kinds of implementation-level changes to make,
> but at the moment I'm focussed on the user experience.)
Keep up the good work :-)
Tel: +44 (1202) 416955
Cell: +44 (7970) 676050