Re: reverse debugging implementation

[David McQuillan <dmcq@fano.co.uk>]

Hi paawan, my replies about what I did..

David

On 25/08/2010 07:30, paawan oza wrote:
 >...
> Firstly as far as I can see gdb saves all the state change for every
> instruction. This is unnecessary, all you have to do is save the state of the
> cpu every few thousand instructions and for each instruction only save the state
> of memory locations before they are changed. Going back one instruction then
> involves rolling back the memory changes, the registers are set up then go
> forward n-1 instruction to go back one.
>
> oza : so does it mean that instructions which changes memory you can take one
> step backward, but instructions which have changed registers you can not step
> back by one instruction but n-1. so we lost the ability to track back by
> instruction, yes of course it is performance gain by the factor of n.

No, every single step backwards involved going back to the last time the 
registers were saved unrolling the memory changes on the way. The 
simulators kept the instruction count so I simply set them to stop when 
they executed the current instruction count - count when registers were 
saved - 1 instructions. The only special code in the simulators was to 
do the before looks of memory writes so it was quite a minimal change 
for existing simulators.

 >...
> I think practically everything else I had about what to do about library calls
> is there - I intercepted system calls so they weren't redone just the old
> results returned so I had to save both before and after looks. Special work had
> to be done about allocating and freeing space and I only had serial files and no
> special device access so you can see I had a fairly straightforward environment.
>
> Oza: ->  Is it possible to revoke all system calls, such as revoking sent signal
> etc, doesnt it ned kernel change in all cases and probably making ptrace more
> powerful. ?

No, I simply saved any the memory the system calls would change plus the 
registers after the call. Actually I didn't save the state afterwards, I 
used the same space for the before look and it swapped between being the 
before look and the after look depending on whether I had rolled to 
before the call. The system calls were not redone when going forward 
after having looked at a previous point. Thus  for example if you rolled 
back over typewriter input on going forward it would return what was 
typed the last time.

I didn't actually free memory at the time a free was done. That was 
delayed until I'd used up too much space on saving memory before looks 
and was then freed at the same time as that.

The serial files bit was a special to allow changes to be made to the 
state after rewinding to a previous point and also one might want a 
monitor file to be written to again rather than just setting the memory 
when redoing instructions going forwards. If one only has serial files 
and a simple environment one can change the previous state, then before 
going forward one has to reset the file pointers and free any memory 
that was allocated at a future point. It could be done with something 
more complicated but that was my only need and I actually didn't need to 
do it much - being able to view what went wrong in detail going 
backwards and forwards is quite enough facility for most purposes when 
debugging without trying to roll back the system in general.

> If you used virtual memory tricks it might be possible to save the state of the
> memory that way instead of even taking before looks. It would slow going
> backwards a bit but I never noticed any particular delay going back an
> instruction and machines have sped up and there's lots more memory nowadays.
>
> Oza ->  does it involve saving whole virtuall address space on disk or something
> ?

No I was just pointing out that one could set the writeable pages read 
only after saving the registers then just copy whole pages and set them 
writeable as required going forwards. It's not something I did but it 
would mean the simulators needn't even do memory before looks and if the 
time between register saves was made something like a few million 
instructions rather than the few thousand I did it would be quite 
economic on memory. It might help with dealing with memory frees 
properly as well rather than leaving the space visible like I did. Going 
back a few million instructions and forward again would be practically 
instantaneous as far as a user is concerned with modern processors.

On performance with the way I did it I always ran with it so a backtrack 
could be done and had it set so it could go back a few million 
instructions before the earlier bits were thrown away. The saving of the 
memory was only a small overall overhead on speed.

David