Re: reverse debugging implementation

[paawan oza <paawan1982@yahoo.com>]

Hi,

I am not sure whether that implementation will improve performance drastically 
compare to existing gdb reversible debuggin implementation.
as
does it involve 

-> stopping at every insn and find out whether insn is changing register or 
memory, and if register then record it (probably not every insn but depends on 
interval and no of memory changing insns)

-> when you want to go back, you go back n-1 and forward execution till 
current-1, that probably involves single steeping which has performance impact.

of course the record for memory is saved as we do not need to save architectural 
state at every insn, but performance !!

Regards,
Oza.




----- Original Message ----
From: "Engblom, Jakob" <Jakob.Engblom@windriver.com>
To: gdb@sourceware.org
Sent: Thu, September 2, 2010 12:18:02 PM
Subject: RE: reverse debugging implementation

> > 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.

If you go back in the gdb mailinglist, you will see that this is exactly
how Wind River Simics does its reverse execution.  Back up to a recent
checkpoint, and then reexecute forward to some point in time.  Silently
record any breakpoints, and if you are running breakpoints backwards, go
back to the checkpoint again and reexecute forward to the point in time
where the breakpoint hits.  

Works very well for a full-system simulator where the entire target
state is encapsulated and controlled.

I believe similar things have been done in the RTL simulation field in
the 1990s, but I have only anecdotal evidence.  If you have
checkpoints/snapshots and a deterministic simulator it is an "obvious"
thing to do.

/jakob


Jakob Engblom | Wind River | Technical Marketing Manager - Simics
Stockholm, Sweden
mobile +46 734 368 958 | email jakob.engblom@windriver.com