This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: reverse debugging implementation
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