This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: [discuss] semantics, "replay debugging" vs. "reverse debugging"
> > Sorry I am wrong.
> > In ARM, Just adds set cpsr reg. So:
> > add r0,r0,#10
> > Can reverse without record too.
>
> OK, well, I was really speaking in the abstract.
> I only meant "it's possible to imagine a target or
> architecture in which reverse execution can be done
> by some means other than record/replay".
>
> Didn't necessarily mean that it could be done on any
> real, existing architecture.
Just to add some more to this:
1. Simics is such a target, as is really any deterministic simulator that is
running without any asynchronous (from the perspective of the simulator program)
inputs. Typical cases involve booting a machine, which tends to be
non-interactive. Or running a program that has all its input data compiled into
it or read from some place that is already on the target. And you could say
that this is a degenerate form of record, since you DO have to "record" the
initial state in some way, even if the initial state is something that you write
yourself as a simulator configuration. It is recorded in a form that can be
brought back identically.
2. There are some odd-ball ideas in computer architecture close to the thinking
behing transactional memory where you do checkpoint and restore and reexecute
inside an actual physical CPU core. These might also for limited scopes support
reversing without replay.
But in general, the only way to get back to an earlier state is to record how to
get there, usually from some even earlier point. Alternatively, use a
tape-recorder analogy and just have a limited buffer with interesting data.
Best regards,
/jakob
_______________________________________________________
Jakob Engblom, PhD, Technical Marketing Manager
Virtutech Direct: +46 8 690 07 47
Drottningholmsvägen 14 Mobile: +46 709 242 646
11243 Stockholm Web: www.virtutech.com
Sweden
________________________________________________________