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

[Mark Burton]

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?

Cheers

Mark.


On 19 May 2013, at 09:21, Peter Maydell wrote:

> On 19 May 2013 05:37, Rob Landley <address@hidden> wrote:
>> On 05/17/2013 12:23:51 PM, KONRAD Frédéric wrote:
>>> It appeared that the replay is not deterministic even with icount:
> 
>> You're aware that reverse execution means you have the "come from" problem,
>> right? (The opposite of goto.)
>> 
>> You literally _can't_ figure out your control flow by running the code
>> backwards. It's equivalent to solving the halting problem. The best you can
>> do is log and replay.
> 
> Yes, of course -- 'reverse execution' is just the usual phrase
> for the user-visible effect. However if your *forwards* replay
> isn't deterministic then it all goes pear-shaped, which is
> what Fred is complaining about.
> 
> -- PMM


         +44 (0)20 7100 3485 x 210
 +33 (0)5 33 52 01 77x 210
 707-356-0783 x 210
        +33 (0)603762104
        mark.burton