From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5899 invoked by alias); 17 Sep 2005 22:19:09 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 5890 invoked by uid 22791); 17 Sep 2005 22:19:05 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 17 Sep 2005 22:19:05 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1EGl1O-0002oR-Ns; Sat, 17 Sep 2005 18:18:58 -0400 Date: Sat, 17 Sep 2005 22:19:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: GDB Patches , jrydberg@virtutech.com Subject: Re: [RFC] reverse-step, reverse-next Message-ID: <20050917221858.GJ8777@nevyn.them.org> Mail-Followup-To: Michael Snyder , GDB Patches , jrydberg@virtutech.com References: <431F6D55.5040501@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <431F6D55.5040501@redhat.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-09/txt/msg00132.txt.bz2 On Wed, Sep 07, 2005 at 03:44:37PM -0700, Michael Snyder wrote: > This isn't for submission, just for discussion. This is something > that Johan Rydberg (of Virtutech) and I have been working on. > > I'd like to hear what everybody thinks about this > bit of infrun implementation for the reverse debugging > that we discussed a few months ago. > > This part is enough to get step and next to work in reverse, > based solely on the assumption that the backend (or someone) > provides an interface "get_exec_direction ()", which returns > forward or reverse. It's also assumed that the backend will > know which direction to go (leaving user-interface issues > out of the picture). One can imagine either a "set direction" > interface, or a "reverse-step/reverse-continue". > > This is actually tested and working with the Simics simulator. > It steps and nexts backwards like a champ. > > The only other bit of explanation that might be required > is that "NO_HISTORY" means you were going backward and > the target ran out of state data (you reached the beginning > of time). The whole thing looks generally plausible to me, too. My only comment is that all the twisty bits of infrun that you're modifying are crying out in the night for someone to gut them and replace them with something more legible. And hopefully to think about backwards execution while doing that. But in the mean time, that's a bit much to ask of anyone. -- Daniel Jacobowitz CodeSourcery, LLC