This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
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

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]