Re: Tracepoint enhancements

[Jeremy Bennett <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
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