From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1141 invoked by alias); 17 Jun 2008 18:22:33 -0000 Received: (qmail 1119 invoked by uid 22791); 17 Jun 2008 18:22:31 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 17 Jun 2008 18:22:13 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m5HIMBFb006487; Tue, 17 Jun 2008 14:22:11 -0400 Received: from pobox-3.corp.redhat.com (pobox-3.corp.redhat.com [10.11.255.67]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5HIMAbB006249; Tue, 17 Jun 2008 14:22:10 -0400 Received: from topaz.toronto.redhat.com (topaz.yyz.redhat.com [10.15.16.227]) by pobox-3.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m5HIMAqv013692; Tue, 17 Jun 2008 14:22:10 -0400 Message-ID: <4858013F.1090507@redhat.com> Date: Tue, 17 Jun 2008 18:22:00 -0000 From: Dave Brolley User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: sid@sources.redhat.com CC: gdb@sources.redhat.com, Michael Snyder Subject: Re: [patch] Reverse Execution in SID, Reverse Debugging with GDB and SID References: <450EF997.1010601@redhat.com> In-Reply-To: <450EF997.1010601@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact sid-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: sid-owner@sourceware.org X-SW-Source: 2008-q2/txt/msg00002.txt.bz2 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 >