RE: Tracepoint enhancements

["Jakob Engblom" <jakob at virtutech dot com>]

> > 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.
> 
> Just my personal opinion, I would find that confusing.
> 
> It seems useful to maintain a fairly sharp distinction
> between breakpoints and tracepoints, since their behavior
> is entirely different from both the implementation and the
> user's point of view.
> 
> But I would not plan to make a fuss about it...

In a simulator, they might be the same. In both cases, the main mechanism is
noting that you reach a certain place in the code or read or write som memory
position. Whether you then note it down and continue or stop execution or call
some callback does not matter. So they can be very much the same. 
 
> > 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.
> 
> That could be interesting to talk about.
> 
> Right now, I think checkpoints are only implemented for native
> linux, and maybe a few other (native) targets.  Whereas tracepoints
> are traditionally associated with remote targets.
> 
> I am very interested in defining a remote protocol that could
> tell the remote target "take a checkpoint" or "restore to a
> checkpoint".  Ideally it should be entirely agnostic about how
> a checkpoint is actually implemented.

If by checkpoint you mean "some point inside the execution of a single program"
this is also a nice fit with simulators (and I presume VmWare as well, if we use
its snapshotting ability for this).  I think this is a very good idea that works
very well with a smart remote target. 
 
> I talked about this with somebody once (can't remember who),
> but I remember the discussion got hung up over whether gdb or
> the target should actually manage the list of checkpoint IDs.
> 
> My thinking is that gdb will probably want to number them with
> simple ordinal numbers (1, 2, 3...) like breakpoints, but that
> the target may have a different type of ID in mind (such as
> process/fork IDs), and somebody will have to maintain a mapping.

The target might have its own interface for looking at such checkpoints... so I
think passing name strings make the most sense.  In Simics, for example,
bookmarks as we call them have names and that is how we work with them.

> Not very different from threads, actually...

I think it is. It is a snapshot of the system state that you can back to, not
really a thread. Only if you consider the odd Linux implementating with fork et
al are they the same.
 

Best regards,

/jakob

_______________________________________________________

Jakob Engblom, PhD, Technical Marketing Manager

Virtutech                   Direct: +46 8 690 07 47    
Drottningholmsvägen 14      Mobile: +46 709 242 646   
11243 Stockholm             Web:    www.virtutech.com  
Sweden
________________________________________________________