This is the mail archive of the
mailing list for the GDB project.
Re: Simics & reverse execution
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).