From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20190 invoked by alias); 19 May 2005 13:46:40 -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 15993 invoked from network); 19 May 2005 13:41:52 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 19 May 2005 13:41:52 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DYlHa-0004JP-8I; Thu, 19 May 2005 09:41:50 -0400 Date: Thu, 19 May 2005 13:46:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Michael Snyder , gdb@sources.redhat.com Subject: Re: [discuss] Support for reverse-execution Message-ID: <20050519134150.GB15632@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c55783$Blat.v2.4$d6ab25c0@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00188.txt.bz2 On Fri, May 13, 2005 at 09:19:17AM +0300, Eli Zaretskii wrote: > > I propose we add something like the following commands > > (names open to discussion): > > > > reverse-continue -- start executing backwards until something > > interesting happens (most likely hitting a breakpoint). > > > > reverse-stepi -- "un-execute" the previous instruction. > > > > reverse-step -- "un-execute" the previous source line. > > > > reverse-finish or "un-call" -- proceed backward until > > the current function is about to be called by its caller. > > > > reverse-until... etc. > > 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, which is a natural parallel. The program doesn't have a persistant direction. If it's stopped, "continue" will always move forwards in time and "reverse-continue" will always move backwards. "back-step" is kind of appealing, but "back-continue" and "back-next" just don't sound right. I suppose we could use "continue-backwards"? I would just have called the command rcontinue, but reverse-continue is fine with me too; either way we'll hopefully offer abbreviations, like "c" and "si". > > Along with these commands, we would need at least two new > > remote-protocol messages: "rc" for reverse-continue, and "rs" > > for reverse-stepi. I think all of the above user commands could > > be implemented on these primatives. Obviously if the remote > > target doesn't understand these primatives, the user command > > would error. You used rc, Johan used bc. It should be consistent with the command names. I wish one of you had noticed vCont though, at least as an example :-) `vCont'[;ACTION[`:'TID]]... -- extended resume Resume the inferior. Different actions may be specified for each thread. If an action is specified with no TID, then it is applied to any threads that don't have a specific action specified; if no default action is specified then other threads should remain stopped. Specifying multiple default actions is an error; specifying no actions is also an error. Thread IDs are specified in hexadecimal. Currently supported actions are: Hmm, thinking about this some more, maybe not such a bright idea. The documentation would need some clarification, since even if we someday have a simulator which both supports reverse execution and presents a view of multiple threads (the implications are dizzying) I'm sure it will be strictly limited in how you can back up the program. Backing up one thread while running another forwards, or even while leaving another stopped, doesn't make sense - it creates a view of execution which never occurred in the previous run. However, there are still two advantages to vCont: consistency, and a pre-existing query packet, vCont?. I'm not dead set on this idea; the benefits of consistency are pretty small in this case and the thread-specific expressive power of vCont is not obviously useful for reverse execution. However I think a query packet is still wise. This allows a front end to modify its interface based on whether the target supports reverse execution without having to try it. > > Finally, we'd need a new entry for the target vector -- > > something like "to_resume_backwards". If the target vector > > doesn't export this method, the user command would error. Whichever name we settle on let's be consistent - if we use "reverse" for the commands and documentation, we should use if for the target hook too. > Please don't forget the manual changes for these features. Definitely! -- Daniel Jacobowitz CodeSourcery, LLC