This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Simics & reverse execution
> 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?
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.
/jakob