Tracepoint enhancements

[Stan Shebs <stan@codesourcery.com>]

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.

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.

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.

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

Stan