This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: reverse debugging implementation
- From: "Engblom, Jakob" <Jakob dot Engblom at windriver dot com>
- To: <gdb at sourceware dot org>
- Date: Wed, 1 Sep 2010 23:48:02 -0700
- Subject: RE: reverse debugging implementation
- References: <4C712882.9040700@fano.co.uk> <312153.55254.qm@web112503.mail.gq1.yahoo.com> <4C7566D3.70109@fano.co.uk>
> > 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