RE: reverse debugging implementation

["Engblom, Jakob" <Jakob.Engblom@windriver.com>]

> 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
till
> current-1, that probably involves single steeping which has
performance
> 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
tradeoffs.

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
http://blogs.windriver.com/engblom/2010/04/what_is_simics_really.html
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. 

/jakob