Simics & reverse execution

[Greg Law]

Jakob Engblom wrote:
>> If the 64 bits of the integer were to be considered 'opaque' and no more
>> than a unique handle onto a point in history, that would be fine.  But
>> such a restriction is unfortunate, because you wouldn't be able to e.g.
>> binary chop history.
> 
> But on which side of the debugger connection would you do this?

I was assuming it would be driven by the gdb side.  One can imagine 
"smart" targets that allow optimized binary chop type stuff.  But it 
seems reasonable to assume that not all targets will have such smarts.

Most important I think is to enable the user to do the binary chop.  It 
might not be a straight-forward thing they're looking for, and in 
general it would be a very useful thing for the user to be able to say, 
essentially, "back a bit, back a bit more, forward a bit".

For that to work we need some way for gdb to know about and be able to 
control a point in history relative to other points in history.

As I mentioned earlier, a way to convert between an opaque handle and a 
scalar value would allow this (this is what UndoDB does right now).  An 
alternative take would be to enable gdb to query and set the percentage 
through recorded history we are right now.  That is, use two interfaces: 
one to get/set an opaque, unique timestamp ID (used for bookmarks) and 
another to get/set the percentage of the way through the record log we 
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 don't have strong opinions on exactly how the protocol should express 
this.  But I do think we need a "precise" notion of time (e.g. for 
bookmarks) and a "relative" notion of time (e.g. for displaying a 
slide-bar in a GUI).  If we're to use the same "type" to do both jobs, 
an 8-byte integer is a bit restrictive.  If we're to use different types 
(probably with conversion between the two), then each being an 8-byte 
integer is fine.


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