Re: Tracepoint enhancements

[Michael Snyder <msnyder at vmware dot com>]

Jakob Engblom wrote:
> > > 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. 

Yes, that's what I meant.  A "point in time" in the execution
history, something that could be represented eg. by a cycle count
or instruction count, rather than just by a PC.

Something corresponding to a snapshot or bookmark.


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

Right -- so for you an internal representation might look like a string.
For VMware, it would look like a pair of integers.  If we did an
implementation linux gdbserver, in which gdbserver did the "fork
trick" (like gdb does now), then the internal representation would
be a process ID.

But for all of these, gdb might keep an external representation
that just looked like a counting integer -- as it does for breakpoints
and threads.  That way the user would have a common interface
(eg. "restore 3"), no matter which target.


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

Sorry, I just meant "like threads in that we have a counting
integer representation on the GDB side, even though there are
various internal representations on the target side".