From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19448 invoked by alias); 20 May 2005 17:41:43 -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 19400 invoked from network); 20 May 2005 17:41:35 -0000 Received: from unknown (HELO shearer.org) (210.10.97.33) by sourceware.org with SMTP; 20 May 2005 17:41:35 -0000 Received: from localhost ([127.0.0.1]:59421 helo=shearer.org) by shearer.org with esmtp (Dan's MTA 1.0) id 1DZBV8-0002ex-Iu; Sat, 21 May 2005 03:11:34 +0930 Received: from dan by erizo.shearer.org with local (Spammer Slammer 3.141) id 1DZBV7-0002eu-II; Sat, 21 May 2005 03:11:33 +0930 Date: Fri, 20 May 2005 17:41:00 -0000 From: Dan Shearer To: Paul Schlie Cc: gdb@sources.redhat.com Subject: Re: [discuss] Support for reverse-execution Message-ID: <20050520174133.GT19642@erizo.shearer.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: Organisation: shearer.org User-Agent: Mutt X-SW-Source: 2005-05/txt/msg00225.txt.bz2 On Fri, May 20, 2005 at 11:49:08AM -0400, Paul Schlie wrote: > Rather than... 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. An alternative point of view: right now nobody has deep experience with reversible debugging and so it seems a little early to make across-the-board structure changes based on limited understanding. 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. In general I really like the idea of GDB better catering to non-remote simulators. You'll notice that almost none of the whole-system simulators in the free software world have integrated debugging and I'd love to make that easier. It's just that the reversibility property is new and I think it will take some getting used to. > More specifically, as ISA semantics do not generally have deterministic > reciprocal semantics, What do you mean by "ISA" in this context? > 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) Isn't this getting out of scope for GDB's current design? If you're going to provide this meta-system command to the simulator why not provide others, like "load-image-file " to initialise the simulator or "enable-skip-idle" to make the simulator skip idle loops and other simulator-specific commands. Again, I like the idea of making GDB closer to simulated environments, but I think it probably needs to be a specific choice to do this rather than just as a byproduct of supporting reversibility. > - (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.) Can you explain what kind of a facility you imagine GDB might have to support doing diffs inherently? > 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.) Unless I've misunderstood you are proposing that GDB have the ability to accept and manipulate entire memory state and diffs of memory state. This is quite a large chunk of new functionality. -- Dan Shearer dan@shearer.org