From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26591 invoked by alias); 21 May 2005 15:03:49 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26288 invoked from network); 21 May 2005 15:03:36 -0000 Received: from unknown (HELO sccrmhc12.comcast.net) (204.127.202.56) by sourceware.org with SMTP; 21 May 2005 15:03:36 -0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc12) with SMTP id <2005052115033501200bak51e>; Sat, 21 May 2005 15:03:35 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 21 May 2005 15:03:00 -0000 Subject: Re: [discuss] Support for reverse-execution From: Paul Schlie To: Daniel Jacobowitz , Dan Shearer , Message-ID: In-Reply-To: <20050521015640.GA17522@nevyn.them.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00267.txt.bz2 > From: Daniel Jacobowitz >> On Fri, May 20, 2005 at 09:52:45PM -0400, Daniel Jacobowitz wrote: >> Frank has contributed that sid would more readily support the sort of >> snapshot-based reconstruction that you're talking about (thanks Frank). >> I think that allowing the target to provide infrun with a view in which >> "single step backwards" is possible and then implementing that under >> the covers in the target stack would still be the way to go - but I >> don't think that's a legitimate objection to supporting a smart >> simulator which does it internally. > > BTW, a thought to consider - again, one which will only be interesting > when there's a system to which it applies. > > What most of these single-stepping commands want to do, in the absence > of watchpoints, is see the PC sequence over a timeline, choose a > stopping state, and go to that state. For some simulator it may be > substantially more efficient to just ask the target for a history of PC > values for some number of cycles, all at once, and then tell it which > one of those we're interested in. That would work for reverse-next, > for example. - Tracing a subset of the states is one thing, tracing and recording all states can be quite another; where like most things, the significance of "some" vs. "all" is relative to the detail inherent in the model of the system being simulated. In the simplest ISA simulation case without attempting to model a complex HW world around the processor in detail, it's not necessarily unreasonable to record all of the most recent N cycle states, presuming N is large enough to be useful; although tracing anything likely reduces simulation performance by at least a factor of 10 vs. tracing nothing between termination points, it's not likely a big deal when a typical simulation interval may only otherwise require a fraction of a second, but can easily become a big deal when the complexity of a simulation may otherwise be measured in minutes (as the very nature of interactive debugging implies some minimal latency so the pilot doesn't feel compelled to take naps while attempting to interactively analyze their system's behavior between supposedly interactive requests; as otherwise things become counterproductive, as the pilot can easily loose their train of thought). > I don't know the level of computation involved in these snapshots in > Simics; perhaps an intelligent simulator, when told to go backwards, > would reconstruct a series of "frames" all at once and cache them, so > this is a non-issue. For some other simulator not yet available, > perhaps it's not. - Not to be too redundant, but just to try to emphasis the one point which I do feel is important; which is that it's likely important for GBD to initially define a set of commands which are most likely easily supported, as it's likely better to have broad multiple target support for a simpler set of capabilities, than very limited target support for a sophisticated set of capabilities in the absents of the former; "undo/reverse" essentially represents this minimal baseline command functionality, all others are substantially more complex to support in the general case.