Re: [Qemu-devel] [RFC] reverse execution.

["Pavel Dovgaluk" <Pavel.Dovgaluk@ispras.ru>]

Hello.

> Spot on Peter,
> The (simplistic) plan is simply to take a snapshot at regular intervals, when you want to step
> backwards, you return to a snapshot, and then re-run forwards to 'just before you started'.
> 
> To answer Blauwirbel, we can't "approximate" this - or 'binary search' for the right place -
> we absolutely have to know exactly how to stop exactly 'just before'. To do that we need a
> measure of where we are. Time isn't really what we want (It has a nasty habit of moving
> forwards even when we are pretending to reverse it!). Ideally we need an instruction count. (I
> say ideally, we could actually get away with something like a block count, but if blocks are
> linked together etc, we would have to be careful).
> 
> I still favor a dedicated counter for this, it seems to make more sense. But - I am wondering
> about a 'basic block counter' rather than an 'instruction counter'.
> 	Note - what I understand by a basic block is something that ends in a jump/branch of
> some description. Hence, one thing I think you can say about a basic block is that each PC
> value within it is unique. Hence, if I know the number of basic blocks executed, and the
> current PC, then I should be able to re-run to there (assuming a deterministic system of
> course).
> 
> I'd be interested to know (a) if there is a sensible place for adding a basic block counter,
> and (b) if people like this route better or worse than an instruction counter?

  We have implemented reverse debugging (through GDB) in QEMU. Translation of the instructions
was changed to increment a special instruction counter before execution of every instruction. 
This counter is used to synchronize events that happen asynchronously in regular execution 
mode (timers, disk operations, etc). Checkpointing is also used in our implementation to 
rollback to previous state and then execute forward.
  Trying to count basic blocks is much more complicated task, because they may be interrupted
with exceptions caused by MMU. Blocks' bounds are not deterministic because they
depend on additional code that you translate, instruction where you stopped (using single-step
or reverse-single-step commands).

  You can find some details here:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=6178942&contentType=Conferenc
e+Publications

Pavel Dovgaluk