From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21328 invoked by alias); 20 May 2005 22:43:01 -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 21153 invoked from network); 20 May 2005 22:42:48 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 20 May 2005 22:42:48 -0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (rwcrmhc12) with SMTP id <20050520224247014001og0de>; Fri, 20 May 2005 22:42:47 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 20 May 2005 22:43:00 -0000 Subject: Re: [discuss] Support for reverse-execution From: Paul Schlie To: Daniel Jacobowitz CC: Dan Shearer , Message-ID: In-Reply-To: <20050520220807.GA11445@nevyn.them.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00250.txt.bz2 > From: Daniel Jacobowitz >> On Fri, May 20, 2005 at 06:01:44PM -0400, Paul Schlie wrote: >>> From: Dan Shearer >>> In the longer term yes, GDB should be able to debug with a sense of >>> direction and time. But I think it will take quite a bit of experimentation >>> before we have a clear model of how to do this, and the only way I can think >>> of for both having a reversible GDB and not touching GDB too much is by >>> considering remote targets first. >> >> - Then you'll end up with nothing more than an interface to a propriety >> simulator, which doesn't seem like a good goal or approach for GDB. > > This argument is so bogus that I need to call you on it. You end up > with a reasonable interface to _any_ simulator, whether proprietary or > not. The details of an efficient implementation will be obviously > dependent on the simulator's state and implementation. - Which is fully your right to claim/believe; however noting the absence of non-proprietary simulators with these capabilities (it's a little unclear how one can presume that interfaces are likely most ideally necessary or appropriate; and simply note that register and memory state by definition is program state, which GDB already has direct access to). > I am inclined to agree with the posted proposals that the > implementation of reverse-stepi should be opaque to GDB, at least for > now. The performance of shuffling state diffs over the remote protocol > - or even just references to them - would be horrid. It also means > that GDB will be limited to a particular class of implementations of > reversible simulation instead of the concept of reversible simulation. - There's no magic, defining a interface for a non-existent simulator doesn't yield a functional solution, and given the absents of knowledge of what that the "typical" simulator's interface presumptions are seems a little premature to define in lieu of a solution. As an aside and personal opinion, I happen believe it's not likely good form to define "opaque" interfaces to non-FSF tools without at least simultaneously implementing a non-opaque/proprietary solution (which is I guess the same philosophical problem that I have with the sourcing of any information, including potentially proprietary extended register/ISA definitions through an "opaque" interface/wall). > You're describing something which may be interesting, someday. Do feel > welcome to implement it; we'll be glad to help. I don't think that > it's inherently more appropriate than the proposed interface, though. - It was just offered as a potential alternative based on a different philosophical view; which I may consider doing something with as time and inclination may allow, and do appreciate the offer for assistance if/when that time comes.