Re: Tracepoint enhancements

Jeremy Bennett
2008-11-03T09:12:33Z

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
user community.

> 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
consistently.

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
changed.

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 :-)

HTH,

Jeremy
--
Tel: +44 (1202) 416955
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com