Re: Simics & reverse execution

[Greg Law <glaw@undo-software.com>]

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/