From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17368 invoked by alias); 19 May 2005 18:46:09 -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 7040 invoked from network); 19 May 2005 17:51:18 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 19 May 2005 17:51:18 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id j4JHpI7R005812 for ; Thu, 19 May 2005 13:51:18 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id j4JHpHO07183; Thu, 19 May 2005 13:51:17 -0400 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id j4JHpFa8027801; Thu, 19 May 2005 13:51:16 -0400 Message-ID: <428CD213.9050304@redhat.com> Date: Thu, 19 May 2005 18:46:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Daniel Jacobowitz CC: Eli Zaretskii , gdb@sources.redhat.com Subject: Re: [discuss] Support for reverse-execution References: <00c601c55747$860a3e80$aaa56b80@msnyder8600> <01c55783$Blat.v2.4$d6ab25c0@zahav.net.il> <20050519134150.GB15632@nevyn.them.org> In-Reply-To: <20050519134150.GB15632@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00202.txt.bz2 Daniel Jacobowitz wrote: > 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". Yeah, I was thinking of "reverse-continue" as the long-form, and anticipating one or more abbreviated aliases such as rcontinue or rc. >>>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. Johan? Is there a conversation that I missed? > I wish one of you had noticed vCont though, at least as an > example :-) Thanks for bringing it to my (our) attention. > [threads] Yeah, as I currently think of it, reverse execution would deterministically reiterate (or de-iterate) what happened before -- therefore you cannot expect to change the course of the execution while running in reverse. Any interferance with thread scheduling would change the outcome (income?) If you first back up, and then shift into forward again, that's another story... > 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. My thinking was (admittedly old-school): just try it, and if the target doesn't understand it, then report accordingly to the user. But I'm totally open to other suggestions. >>>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. Sure. >>Please don't forget the manual changes for these features. > > > Definitely! Sure. ;-)