Re: Tracepoint enhancements

[Michael Snyder <msnyder@vmware.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".