This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]