Simics & reverse execution

[Michael Snyder]

Jakob Engblom wrote:
>> I think we just need to come up with a sufficiently arbitrary
>> way to represent both a "point in time" and a "bookmark", so
>> that they can be passed back and forth between gdb and the
>> remote target without gdb needing to know what they actually
>> represent (eg. a timestamp or a branch count).  Only the target
>> needs to know how to interpret them.
>>
>> Maybe an 8 byte integer would be sufficient?  What do you think?
> 
> I think a logical clock is the only sensible solution, actually, as you say, we
> cannot know the time. In Simics, we use cycle counts, and bookmarks are just
> names for a particular cycle count point.  A good question is whether bookmarks
> should be part of state in gdb or in the backend or both.
> 
> Obviously, there are nasty corner cases that are too complex for this protocol
> to handle.  In particular, if you are using a temporally decoupled simulation
> engine where multiple processors are run for time slices before switching to the
> next, there is a minor chance that you can see time jump back and forth (local
> time on th current processor) as you execute logically forward... our tools
> handle that, but it is pretty hard to do right and I don't expect gdb to have to
> deal with that. Let the backends do it.

I think we're saying the same thing.  GDB doesn't know anything about
logical clocks.  The target (simics/process record/vmware/whoever) can
give gdb an arbitrary piece of data to represent a bookmark, and gdb can
give it back again later.  For Simics, it may be a timestamp or logical
clock.  For process record, I think it would be an instruction count.
GDB should not care what it is.

We just need to decide on a data protocol representation for it.

For a UI, we just need to present a list to the user, something like
we do for breakpoints.  Each bookmark (checkpoint?) can be identified
by a small counting integer, and then maybe some target-specific
description such as we do for threads (where the target has a callback
for presenting "thread info" in a user-readable way).