reverse debugging implementation

Engblom, Jakob
Thu Sep 2 12:52:00 GMT 2010

> I am not sure whether that implementation will improve performance
> drastically
> compare to existing gdb reversible debuggin implementation.
> as
> does it involve
> -> stopping at every insn and find out whether insn is changing
> register or
> memory, and if register then record it (probably not every insn but
> depends on
> interval and no of memory changing insns)

Neither. We only reexecute all the instructions, period.  No saving of
state other than at the regular checkpoints (snapshots).

> -> when you want to go back, you go back n-1 and forward execution
> current-1, that probably involves single steeping which has
> impact.

Not really, we run the target system in JIT mode typically, only
stepping the last few instructions if that is in the middle of a
translation unit.  Note that his is using a complete target system
simulator, not at all relying on the host.  Simics can stop at a precise
point in virtual time, that is key to this exercise.

> of course the record for memory is saved as we do not need to save
> architectural
> state at every insn, but performance !!

Note that we also include networks, disks, and the rest of the virtual
world in this approach.  

VMWare is doing something similar with their record/replay, but in a
different way with different performance/portability/generality

In any case, comparing performance with the gdb record-replay system is
not very useful as we atually do something different. First of all, this
is system-level, so you can work with boot loaders, operating systems,
and multithreaded and multicore target.  See
for more on Simics if you are interested.

But I am not here to sonud like an advertisement, I just wanted to point
out that checkpoint/snapshot + deterministic reexecution is a viable way
to do reverse execution. 


More information about the Gdb mailing list