From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32339 invoked by alias); 20 May 2005 13:04:27 -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 31716 invoked from network); 20 May 2005 13:03:43 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 20 May 2005 13:03:43 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DZ7AE-0006hx-AN; Fri, 20 May 2005 09:03:42 -0400 Date: Fri, 20 May 2005 13:04:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Michael Snyder , gdb@sources.redhat.com Subject: Re: [discuss] Support for reverse-execution Message-ID: <20050520130342.GA25206@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Michael Snyder , gdb@sources.redhat.com References: <00c601c55747$860a3e80$aaa56b80@msnyder8600> <01c55783$Blat.v2.4$d6ab25c0@zahav.net.il> <20050519134150.GB15632@nevyn.them.org> <01c55d2a$Blat.v2.4$0a36cba0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c55d2a$Blat.v2.4$0a36cba0@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00209.txt.bz2 On Fri, May 20, 2005 at 01:51:31PM +0300, Eli Zaretskii wrote: > > Date: Thu, 19 May 2005 09:41:50 -0400 > > From: Daniel Jacobowitz > > Cc: Michael Snyder , gdb@sources.redhat.com > > > > > Not "reverse", "backwards" or "back". "Reverse" will become ambiguous > > > once we have two possible directions. > > > > Actually I think "reverse" is a more logical term. Drivers don't > > seem to get confused when they put a car into reverse > > One can learn anything, given enough practice. So the fact drivers > can get accustomed to this doesn't mean it won't be harder for GDB > users. Most people don't use GDB as frequently as they drive cars. But many GDB users drive cars :-) Anyway let's not go there. You think it is ambiguous; I disagree. > > The program doesn't have a persistant direction. > > I envision that adding this could be a natural extension. Using > "backwards" rather than "reverse" will save us from the ambiguity if > we ever add such a feature. I really don't think that we should have such a feature. It seems like a crummy interface - a resume command which goes either forwards or backwards in time depending on some global state? I think that auto-repeat when you hit return at a GDB prompt is all we want to have, and we already have that. > > "back-continue" and "back-next" just don't sound right. > > Neither does "reverse-next". Perhaps we should use "prev" instead. It seems to me that if we give them unique names, the logical parallel with existing commands may be lost. But perhaps not. Let's try for the full set: continue reverse-continue step reverse-step next reverse-next stepi reverse-stepi nexti reverse-nexti until reverse-until advance reverse-advance finish reverse-finish I think that's the full set of reversible commands. Which of them don't work? I agree that reverse-next is a little weak, but everything else seems OK. And we aren't limited to one name for things! We could add "prev" as an alias to "next" if you like that. We could use r-prefixed commands. I don't think that helps much, since we're already planning to offer abbreviations like "rs" and "rni", but they're my second-favorite choice: rcontinue, rstep, rnext, rstepi, rnexti, runtil, radvance, rfinish We could use "backwards" for everything. Those mostly sound right, except that backwards has some unfortunate connotations. I think that advance and finish come out as particularly odd: backwards-continue, backwards-step, backwards-next, backwards-stepi, backwards-nexti, backwards-until, backwards-advance, backwards-finish This one's kind of nice, we could use suffixes instead. But next-backwards is very awkward: continue-backwards, step-backwards, next-backwards, stepi-backwards, nexti-backwards, until-backwards, advance-backwards, finish-backwards -- Daniel Jacobowitz CodeSourcery, LLC