From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15775 invoked by alias); 20 May 2005 15:49:31 -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 15547 invoked from network); 20 May 2005 15:49:20 -0000 Received: from unknown (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sourceware.org with SMTP; 20 May 2005 15:49:20 -0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (rwcrmhc11) with SMTP id <2005052015491001300qpldue>; Fri, 20 May 2005 15:49:19 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 20 May 2005 15:49:00 -0000 Subject: Re: [discuss] Support for reverse-execution From: Paul Schlie To: Daniel Jacobowitz , Eli Zaretskii , Michael Snyder , Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00223.txt.bz2 Alternatively to attempting to specify an interface to a lone commercial reversible simulator, or presume the intelligence need be "remote" to GDB; 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. More specifically, as ISA semantics do not generally have deterministic reciprocal semantics, it's only possible to support reverse execution by literally being able to either maintain a list of all state changes associated with each instruction/command's execution and unwind them, and then optionally proceed forward again. Therefore it seems likely sufficient to initially begin by defining support for the following core facilities: Basic GDB support for check pointing and reverse execution: - enable-checkpoints: initializes machine state and program memory to all 0's upon prior to program startup/initialization. (see below) - save-checkpoint [Optional-Name] => checkpoint [N [Optional-Name]], saves a diff between the programs present state and it's previous state, and marks the current undo-state diff (see below) as being equivalent to this checkpoint. - restore-checkpoint [N | Opional-Name]; sets machine and memory state to the cumulative difference between all 0's and the designated checkpoint diff. [this is insensitive to the target's stub supporting state-diff, as GBD is responsible for storing and computing state-point restores on behalf of the target] - enable-undo/reverse: sets flag to request state-diff from target stub upon (step, next, etc.) commands. - (step, next, etc.): as normal, but requests the state-diff from the target stub between successive command executions if reverse-execution flag is enabled. (This may also be supported without target stub support for state-diff, as GDB has direct access to both the target's machine state, and memory state; although target stubs may likely be capable of more efficient diff's if they are capable of tracking memory updates more efficiently than simply looking after the fact.) - undo/reverse: undoes/reverses the previously issued command, by un-diff'ing the present machine and memory state with the previously returned diff. (which is likely sufficient and substantially more time and resource efficient than attempting to otherwise effectively single-step record all intervening individual instruction execution diff's, which could also be enabled if desired, although likely not necessary in general.) Basic Target stub facilities to improve reverse execution efficiently: - state-diff: the target returns the diff between the target's present state and it's previous state, which may be used if available in lieu of GDB directly calculating machine and memory state diffs, but would likely only be substantially more efficient if the target stub were capable of more efficiently tracking and accumulating diffs by directly monitoring memory state changes, rather than determining them after the fact, as may be done likely efficiently by a target simulator and then simply communicated by publishing the cumulative diffs as requested by GDB; which seems nice and simple, and minimally invasive.)