From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29992 invoked by alias); 21 May 2005 10:28:36 -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 29832 invoked from network); 21 May 2005 10:28:20 -0000 Received: from unknown (HELO mail.netspace.net.au) (203.10.110.76) by sourceware.org with SMTP; 21 May 2005 10:28:20 -0000 Received: from [192.168.1.11] (220-253-29-14.VIC.netspace.net.au [220.253.29.14]) by mail.netspace.net.au (Postfix) with ESMTP id 8E3C91114FB for ; Sat, 21 May 2005 20:28:18 +1000 (EST) Message-ID: <428F0DB8.40804@netspace.net.au> Date: Sat, 21 May 2005 10:28:00 -0000 From: Russell Shaw User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050105 Debian/1.7.5-1 MIME-Version: 1.0 Cc: gdb@sources.redhat.com Subject: Re: [discuss] Support for reverse-execution References: <20050516174649.GM19642@erizo.shearer.org> <20050520181515.GC2499@nevyn.them.org> <01c55ded$Blat.v2.4$11e9e260@zahav.net.il> In-Reply-To: <01c55ded$Blat.v2.4$11e9e260@zahav.net.il> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00260.txt.bz2 Eli Zaretskii wrote: >>Cc: Dan Shearer , gdb@sources.redhat.com >>From: fche@redhat.com (Frank Ch. Eigler) >>Date: 20 May 2005 20:05:13 -0400 >> >>The point of the other simulation gentleman on this thread is that by >>using state snapshots as the basic target-side primitive, one can >>implement backward stepping on the gdb side in a way that will work >>even with non-brilliant targets. (By the way, this does not require >>actual bulk transmission of the state snapshots to gdb, just some sort >>of management protocol.) > > > This leads me to another idea. Perhaps we should implement a > checkpointing infrastructure in GDB, and allow the user (perhaps not > by default, but as part of some mode) to go back to every place where > the program stopped, for whatever reason: breakpoint, watchpoint, > single-stepping, etc. That is, each time the inferior stops, ask the > target for the information that fully describes its state, store that > state description, and allow the user to rewind the target to any of > the stored states. > > I think this would be a great feature to have in all kinds of targets, > including native, since the user can then step forward from the > checkpoint to reach any point in between. > > Think how many times you've did a "next" over a function call, just to > find out that the bug is inside the function which you just > overstepped, or did a "continue" just to find out at the next > breakpoint that the problem you are tracing happened in between this > and the previous stop location. An ability to rewind back to the > previous stop is something to kill for in such situations. > > (Btw, I vaguely remember that Turbo Debugger of yore had something > like that. Hmmm... I should try to dig out my old copy of that and > see if I'm right.) > > If we implement something like that, perhaps we could ditch all the > reverse-* commands whose names we are discussing at such length in > this thread, and instead implement only one command, called, say, > "rewind" or "backup" or some such. That, and a set/show mode command > to enable checkpointing would be enough, I think, to have 99% of the > functionality originally suggested in this thread. > > How would this suggestion of mine map to the remote targets and > simulators that support checkpointing on the target side? It'd be better to store the state of every step in to a circular buffer of size 1000 (the user could change that size with a command). Then you could just: "back 10" to go to the point that would have been 10 steps ago, or "back 3 myfunc" to go back to the third last call of myfunc(). That way, there's only one backwards command to remember, and maybe a command to change the history buffer size.