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

On Tue, 2008-06-17 at 14:23 -0400, Dave Brolley wrote:
> 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.

Woo hoo, so now there is at least one target (xstormy16) 
where we can actually *test* reverse debugging.  Should
be a good step toward committing it to gdb.

> 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
> >