Hi,
The attached patches implement
1) Infrastructure for reverse execution of in SID
2) Target specific implementation for xstormy16
This work is intended to be used in conjunction with Michael Snyder's
work on reverse debugging in GDB, but I suppose that the idea of
executing in reverse need not necessarily be restricted only to this
purpose.
I'm submitting the general infrastructure work for approval to commit.
The xstormy16 specific implementation was done mainly as an example,
and perhaps should also be committed.
Here is an overview of the changes and how they work:
o The changes the the scheduling components are mainly to have them
drive the value of 'now' for each scheduled event. Currently they
drive the value zero which is not used on the receiving end. This
provides a mechanism for a scheduled component to know what 'time'
each scheduled event occurs. Components, like memory, which are not
scheduled, but which need to know at what 'time' an event occurred can
query the scheduler's time attribute to obtain the same information.
The scheduler's set_time method has also been updated so that it
cancels all pending events. This change was probably already
necessary, but the need was exposed during testing of this feature.
o A new component class mix-in called reversible_component has been
created to consolidate the common needs of a component which may have
to step back in 'time'. The main features are a reversible? attribute
which tells the component that it should be keeping track of events
and a restore-to-time! pin which tells the component to restore it's
state to a given 'time'.
o A new utility class called change_log has been added to aid those
components which choose to implement this using change logging
techniques.
o The basic_cpu class has been given specific knowledge of what it
means to execute in reverse. This is controlled by it's new
exec-direction attribute which can be set to "forward" or "backward".
This attribute is checked when the step-insns pin is driven. If the
direction is forward, then it's business as usual. If it's backward,
then the cpu does what is necessary to step backward and then resets
the scheduler to that 'time'. The scheduler in turn drives its
time-set pin to notify other components in the system to restore
themselves to that 'time'. Note that reverse execution need not be one
insn at a time. I did this for the xstormy16 example so that stepi
would work in reverse with gdb. Note that in the xstormy16 example,
breakpoints and watchpoints are also supported while executing in
reverse.
The idea is that components in the system which have state implement
some method of restoring their state to what it was at a given 'time'.
Whatever makes the most sense for each particular component. The cpu
is an obvious example as is memory. More complex systems may have
other components with this requirement. For the xstormy16, cpu and
memory are the only components requiring this capability.
In particular, the xstormy16 cpu component needed only to track
changes in the pc and the gr registers. Using specific knowlege of the
kinds of changes that are possible to the pc, in particular I was able
to implement a change logging system that uses only 1 byte for small
pc changes (i.e. less than 128 bytes) and 3 bytes otherwise. Similarly
for the gr registers, a 2 byte mask indicates which registers have
changed and then only the changed registers are added to the change
log record. Many change log records are therefore 5 bytes or less.
One interesting 'feature' of the current implementation is that if a
program has been debugged to completion and then debugging has started
again (i.e. the gdb 'target' command establishes a new connection with
SID), one can debug backward past the beginning of the program (with a
warning from SID) and back into the previous execution instance. The
feature is handy in the case that you use the GDB continue command and
end up at the end of the program by mistake.
Comments, ideas, and, of course, approval to commit the infrastructure
patch please. I can also commit the xstormy16 specific parts if desired.
Dave