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 <r...@landley.net> 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
