Re: [patch] Reverse Execution in SID, Reverse Debugging with GDB and SID

[Dave Brolley <brolley@redhat.com>]

Micheal Snyder is going to be doing some more work on revserse 
debugging/execution and he reminded me that I never did commit this 
work. It's committed now.

Dave

Dave Brolley wrote:
> 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
>