Re: Simics & reverse execution

Greg Law
2009-09-04T12:44:19Z

Jakob Engblom wrote:
>> currently are (to allow e.g. a graphical frontend to implement a
>> slide-bar to show where in the record log we are). The former is
>> precise to instruction count (and signals, etc); the latter may not be
>> depending on the details of the target. Actually, percentage is the
>> wrong term -- better would be what fraction of the way are we through
>> history, e.g. in 1/(2^64) increments, such that half way through
>> recorded history would be represented as 2^63.
>
> I can see one big problem with this: you are assuming a bounded recording.

No. Or at least, not consciously :)

In the notion above, we're talking about 1/(2^64) of however much log
happens to have been recorded. So yes, if you did a binary chop, then
ran a bit in record mode to "grow" the log, and then did another binary
chop, how much time 1/(2^64) of the log represents would change. But
that's what bookmarks are for -- these would give you a consistent
marker to allow you to jump back and forth as the log grows (or even
shrinks).

But I'm not wedded in any way to the above scheme. Having some way to
convert from an 8-byte 'precise' bookmark to an 8-byte 'imprecise'
scalar representation would also be fine. In the case of Simics it
sounds like such an operation would be a no-op (both bookmarks and
scalar values would be 8-byte picoseconds).

>
> In our case, it is unbounded (except for the current 64 bit counter of
> picoseconds used to coordinate all processors and other time-dependent parts in
> a simulation system, which bounds execution at an annoying 280 days of time).

UndoDB is essentially the same (except our limits take us to about 30
years :)

> In Simics, you can always just continue past the end of the previously seen
> execution, and you extend the size of the reversible window. I believe VMWare
> does the same from my experiemtns with Workstation 6.5.

Right, same for us.

>
> I honestly think binary chop is best put into the backend for this reason... the
> times I have seen it applied it relied on large state-checking scripts running
> that had far better insight into the target system than you get with gdb (such
> as doing global consistency checks on the state of file systems on various
> boards in a fault-tolerant redundant cluster).

Oh, I agree that binary chop intelligence in the back end could be a
good thing. It would be really nice one day to be able to have gdb say
to the back end "find me the most recent time this arbitrary condition
held". However, that's quite complicated, and it seems reasonable to
assume is a little way into the future. More importantly, even when gdb
supports it, it's likely that not _all_ back-ends would. And more
relevant still, whatever binary chop interface were defined, it seems
that in addition it would be useful to export to the user the ability to
jump to an arbitrary point in time, without necessarily having a
bookmark there. Talking purely in terms of binary chop is too limited.
Example - say the user wants to go back to the beginning of time, but
didn't think to take a bookmark when they were there. Executing
backwards might take a long time. For systems like Simics, UndoDB and
VMware that use a snapshot-and-replay technique it can be almost instant
to jump back to time 0. We could always add a special command to goto
time 0 or a special bookmark, but why not generalise it? e.g. maybe the
user wants to skip forwards a few seconds' worth, but again, doesn't
have a bookmark conveniently placed.

It seems that for at least some targets this would be pretty
straightforward to implement and a very useful feature for users.

Cheers,

Greg
--
Greg Law, Undo Software http://undo-software.com/