From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3469 invoked by alias); 20 May 2005 21:35:50 -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 2898 invoked from network); 20 May 2005 21:35:28 -0000 Received: from unknown (HELO sccrmhc11.comcast.net) (204.127.202.55) by sourceware.org with SMTP; 20 May 2005 21:35:28 -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 <2005052021351701100q3nafe>; Fri, 20 May 2005 21:35:27 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 20 May 2005 21:35:00 -0000 Subject: Re: [discuss] Support for reverse-execution From: Paul Schlie To: Michael Snyder CC: Daniel Jacobowitz , Eli Zaretskii , Message-ID: In-Reply-To: <428E4F46.7010501@redhat.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00242.txt.bz2 > From: Michael Snyder >> Paul Schlie wrote: >> Alternatively to attempting to specify an interface to a lone commercial >> reversible simulator, > > I don't think that's what we're doing -- these commands are meant > to be generically useful, as soon as anyone else can support > backwards execution. - Sorry for the misinterpretation; but as noted, it seems generally more useful to simply add the capability to GDB, thereby little if any functionality need be dependant on the target simulator, and further by doing so may actually support both check-pointing and undo/reverse execution, on all existing targets, regardless of whether or not they are simulated, or physical targets. >> or presume the intelligence need be "remote" to GDB; > > We're not doing that either -- the user interface makes no > assumption about the target interface. - Then there seems no need to define a reverse-xxxx set of commands at the GDB/target-stub boundary (unless I misunderstand the purposed of the earlier threads of dialog)? >> I wonder if it may be more sensible to consider initially defining the basic >> generic facilities by which GDB may directly support undoable/reversible >> execution, and checkpoint features. > > Well, that's an idea that some of us (me, at least...) have thought about > too -- but it's, if not orthogonal, at least separable from this discussion. > If gdb asks the target to step backwards or continue backwards, we really > don't care how the target accomplishes this - Sounds like you are presuming the "intelligence" to be remote and distinct from GDB, which I believe is fundamentally a less than an ideal premise. > (eg. whether by restoring a saved state, or actually reversing the execution > of individual instructions). - It should be clearly understood that it's factually impossible to define reciprocal semantics for all instructions; therefore the fundamental basis of any undo/reverse execution facility has to be based on the ability to capture state to revert the "effects" of the execution, not "execute" logically reciprocal instructions. (If this is not understood, then its likely premature to attempt to define any interface to support the capability.) > I've thought all along that the "bookmark" idea is separable from the > "run backwards" idea. - There're essentially identical, with the exception that one captures and provides a vehicle to backup to a previously named/designated (bookmarked) state, the other enables the same but to typically to a previously relative state. (single-step reverse execution in it's most general implementation is nothing more than reversing to a previously sequentially captured instruction by instruction check point diff) By recognizing this, there's no need to rely on any information beyond that which GDB already has access to to implement (although may be improved by by simulators which can capture memory state change diffs more efficiently than by brute force)