Re: Simics & reverse execution

Greg Law
2009-09-01T13:49:21Z

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/