This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Simics & reverse execution
Greg Law wrote:
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?
I just want to interject that, while it is possibly interesting for
us implementers to compare notes about what is represented here,
my proposed idea was that gdb will *not* need to know what is
represented. Precisely because each target internally represents
something different.
I think what we were discussing was a "bookmark" metaphor.
GDB's side of the transaction is to provide a mapping between
something user-friendly (like breakpoint numbers), and something
that the target can use to establish and restore a machine state
(like Greg's list of pointers or Jakob's timestamp or Hui's
instruction count).
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.
Agree. GDB will not do any interpreting of the "cookie" supplied by
the target. Just as GDB does not assume anything about the relationship
between two breakpoints or two threads.
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.
Well, so what we want to do is call out an API that is sufficiently
general so as not to restrict future enhancements.
This is familiar territory in GDB-land, because GDB has to serve
so many different hosts and targets that we just get into the habit
of not assuming *anything*.
For instance, target addresses are represented internally in gdb as
a data type called a CORE_ADDR. We do not even assume an ordering
between CORE_ADDRs (that is, we do not assume that we can compare
them like integers). To compare them, you have to call a method.
Similarly, as a later enhancement, we might specify a target method
for comparing two bookmark cookies. GDB could then ask the target
to order them. But GDB itself will not try to order them.