From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2332 invoked by alias); 20 May 2005 23:32:55 -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 2101 invoked from network); 20 May 2005 23:32:41 -0000 Received: from unknown (HELO sccrmhc13.comcast.net) (204.127.202.64) by sourceware.org with SMTP; 20 May 2005 23:32:41 -0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (sccrmhc13) with SMTP id <200505202332400160063o34e>; Fri, 20 May 2005 23:32:40 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 20 May 2005 23:32:00 -0000 Subject: Re: [discuss] Support for reverse-execution From: Paul Schlie To: Michael Snyder , Message-ID: In-Reply-To: <428E6081.70602@redhat.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00251.txt.bz2 > From: Michael Snyder >>>> 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)? > > > The user interface makes no *assumption* about the target > interface, but that doesn't mean that the target doesn't > *also* need an interface. Both have been discussed in this > thread, but they're not tied together. - I'd just caution against defining user commands which are in general much more difficult and expensive to support; i.e. defining any command which may specify a state which has not been previously likely recorded, as then it implies that the state needs to be unwound to the closest known point preceding it and then forward executed to the new desired state (which the simulation may have never "stopped" at before) More specifically for example, one may step past a function call, where the state preceding and after the call is now known, but the state preceding the previous instruction reverse-step-i may not be supported by the simulator naturally, and may require that the simulation be undone (which is always easiest) to the point preceding the call and then forward executed until the desired preceding instruction state is reached, etc. (Therefore an "undo/reverse" command is most likely the best basis for basic reverse simulation support, as it restricts reverse execution to only those points which the simulator had previously terminated it's simulation at previously; and other commands may be best only defined after such features are more broadly supported by at least a few simulators, and/or by GDB directly. Just as a thought.)