public inbox for
 help / color / mirror / Atom feed
From: Dave Brolley <>
Cc:, Michael Snyder <>
Subject: Re: [patch] Reverse Execution in SID, Reverse Debugging with GDB  and  SID
Date: Tue, 17 Jun 2008 18:22:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

  reply	other threads:[~2008-06-17 18:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-18 19:55 Dave Brolley
2008-06-17 18:22 ` Dave Brolley [this message]
2008-06-17 19:37   ` Michael Snyder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).