[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] reverse execution.
From: |
Pavel Dovgaluk |
Subject: |
Re: [Qemu-devel] [RFC] reverse execution. |
Date: |
Wed, 29 May 2013 16:37:53 +0400 |
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
- Re: [Qemu-devel] [RFC] reverse execution., (continued)
- Re: [Qemu-devel] [RFC] reverse execution., Rob Landley, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Peter Maydell, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Mark Burton, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Peter Maydell, 2013/05/19
- Message not available
- Re: [Qemu-devel] [RFC] reverse execution., Brendan Dolan-Gavitt, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Mark Burton, 2013/05/20
- Re: [Qemu-devel] [RFC] reverse execution., Rob Landley, 2013/05/19
- Re: [Qemu-devel] [RFC] reverse execution., Mark Burton, 2013/05/20
- Re: [Qemu-devel] [RFC] reverse execution.,
Pavel Dovgaluk <=