From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9010 invoked by alias); 9 Jan 2006 08:41:42 -0000 Received: (qmail 8992 invoked by uid 22791); 9 Jan 2006 08:41:41 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 09 Jan 2006 08:41:40 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Evsao-0006VY-4s for gdb@sources.redhat.com; Mon, 09 Jan 2006 09:41:30 +0100 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jan 2006 09:41:30 +0100 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 09 Jan 2006 09:41:30 +0100 To: gdb@sources.redhat.com From: Vladimir Prus Subject: Re: Return to Reverse Execution Date: Mon, 09 Jan 2006 08:41:00 -0000 Message-ID: References: <43BC376F.4000307@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00064.txt.bz2 Michael Snyder wrote: > Over the past several months, there's been some great discussion > of this topic, and even some trial patches sent out for comment. > > I'd like to start preparing a real submission for approval. > I'm testing the waters now, to see how close we may be to > converging on an acceptable interface spec. > > So here is my proposed gdb user interface. > 1) A set of new commands that mimic the existing ones, > to include: > reverse-step (rs) > reverse-next (rn) > reverse-continue (rc) > reverse-finish (rf) I think that you need to specify completely what each of the commands will do. There sure will be some corner cases and it would be better to understand them sooner or later, and for that we need explicit spec. As an example, we have this code: foo(); i = 10; and we're standing at "i = 10" line. Then, "rn" will presumably execute the entire "foo()" line. The problem is that when standing on "i = 10" line user does not know if previous line is function call or not, and what function is called, and so can't easily decide if he wants "rnext" or "rstep" command. Even in GUI, visually scanning for the previous code line is inconvenient. In TUI this will require extra "list" command. Maybe, for reverse execution each "rn/rs" command should show the next line that will be executed with "rn/rs" command, not the one that will be executed by the following "n/s" command (that was just executed by "rn/rs")? Or show two code lines: one that will be executed by "step" and one that will be executed by "reverse-step"? BTW, what about "reverse-until"? Sure's that's just tbreak + reverse-continue so emulating reverse-until in KDevelop will be easy, but for command line reverse-until might be handy. > 2) A mode setting that will cause all execution commands > to be performed in reverse: > set exec-direction [forward backward] > > That gives users the choice of backing up once, or continuously. > > Here's my proposed target vector interface: > > target_ops.to_set_exec_direction (int); > > This keeps the target vector simple -- no need for discreet > vectors for reverse-proceed, reverse-wait etc. If the target > doesn't export this method, it cannot go backwards. Looks reasonable. - Volodya