This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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







Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]