Re: Simics & reverse execution

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

Jakob Engblom wrote:
>> Anyway, 8-bytes is not a sufficiently general representation of time for
>> UndoDB. The trouble is, we don't keep a linear cycle count or such like.
>>   We could in theory, but it would slow us down.  So instead we
>> represent time as a structure.
> 
> What exactly is represented here? Some kind of tree of execution?

No, it's essentially a combination of pointers that we know will 
uniquely identify a point in history.

> 
> If it is a linear execution, couldn't you just map arbitrary points in time to
> integers?
> 
> Also, note that as Michael says, the idea here is to have an ID number that
> passes back and forth between gdb and the target, which is then resolved at the
> target. 
>  
>> So, I think it would be better if the abstract time representation could
>> be an opaque "bag of bits" of arbitrary size.
>>
>> We'd be happy to contribute some patches along these lines, although I
>> don't think we'd be able to do anything in time for the proposed gdb 7
>> branch.
>>
>> What do people think?
> 
> I think it might be unnecessary: unless you need more than 2^64 distinct
> bookmarks/points in time tracked, can't you do a local map in your backend
> between gdb logical bookmark IDs and the internal time representation?
> 
> Note in that in our case, the "time" is not really that simple... when you
> factor in multithreaded simulation of multiboard targets and temporal
> decoupling, Simics typically has ten different "points in time" active at the
> same time... but for reveexec, we untangle this for the benefit of the user. 

I guess my worry is that there would be some kind of ordering associated 
with the time values.

That is, we could use such a mapping, as long as no one assumes that you 
can do an integer compare of two bookmarks or times to know whether one 
is "later" than the other.

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.

Obviously, any opaque bag of bits is going to suffer like that.  What we 
do currently in UndoDB is to have calls to get a relatively course grain 
linear, scalar integer value from an undodb_time_t.  It's coarse-grained 
in that several close together but distinct points in history (e.g. 
adjacent instructions) may get the same scalar value, but in reality not 
many, and so it's enough to do binary chops, etc.

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