From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22760 invoked by alias); 21 May 2005 14:13:28 -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 22462 invoked from network); 21 May 2005 14:13:08 -0000 Received: from unknown (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org with SMTP; 21 May 2005 14:13:08 -0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc11) with SMTP id <2005052114130701100q3m4ve>; Sat, 21 May 2005 14:13:08 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sat, 21 May 2005 14:13:00 -0000 Subject: Re: [discuss] Support for reverse-execution From: Paul Schlie To: Daniel Jacobowitz CC: Dan Shearer , Message-ID: In-Reply-To: <20050521015245.GA17463@nevyn.them.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00263.txt.bz2 > From: Daniel Jacobowitz > On Fri, May 20, 2005 at 09:41:58PM -0400, Paul Schlie wrote: >> - Supporting HW co-simulation is certainly interesting, but fundamentally >> no different; it only extends the definition of "state" typically by >> literally exposing some of the logical CPU/I/O/Peripheral/outside-world >> state in various levels of details depending on the goals of the model, >> and/or simulation itself. (but would guess likely beyond the near term >> goals of attempting to enable GDB support for basic reversible execution?) > > Why should it be? This is another reason that I consider the simulator > a perfectly reasonable place to have the logic. - The predominant downside of such a presumption, is that then NxM targets would need to add support to broadly enable the capability, rather than broadly enabling within GDB, while allowing a target to improve it. > 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. - Possibly the only reasonable way to do, as the ability to "single step backwards" to a state with the simulation environment may have never previously terminated at is substantially more difficult to support efficiently than simply reverting to a previously reached stable state. > - but I don't think that's a legitimate objection to supporting a smart > simulator which does it internally. - I only object (or observe alternatives) to defining a set of commands which are presently apparently unique to a particular commercial tool's abilities, and which if presumed to form the basis of the requirements for reversible simulation could become an impediment for GDB to support simpler more easily implemented facilities. Conversely, if it were initially presumed that the initial basis for reversible simulation were based on the support of a recursive "undo/reverse" command, then it would be much easier for a broader number of targets (and even potentially GDB itself) to support. > When someone implements reversible debugging in a free simulator and > wants to integrate that with GDB, they'll have the choice of doing the > remaining steps in their simulator or in GDB. - Although our views may differ, I accept and support the simple reality that those to invest the time and resources in a development, have the greatest say in the decisions. (In this case if the desire is to define an interface for a single lone proprietary tool, likely in satisfaction or natural result of a commercial commercial contract to do so, then let it be; but attempting to justify it as a good thing is a bit of a stretch). >> [And suspect you'll find that most HW savvy simulation environments have >> very limited if any support for "reversible" simulation, beyond >> checkpoint-restart. As on a cycle by cycle basis, tracking and recording >> incremental state changes would typically cripple the simulation, and >> potentially even exhaust disk storage for complex models, but limited >> forms do exist, and are useful.] > > You might want to read the papers on the specific simulator we're > discussing using as a starting point; you can find the white paper on > Virtutech's web site. Under the covers, of course, it's probably > checkpoint based. But it's efficient, automatic checkpointing such > that it can provide a reversible view over useful periods of time. > Complete with "HW savvy" details. - Thank you.