From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16660 invoked by alias); 21 May 2005 10:13:01 -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 16618 invoked from network); 21 May 2005 10:12:55 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 21 May 2005 10:12:55 -0000 Received: from zaretski (IGLD-83-130-247-87.inter.net.il [83.130.247.87]) by romy.inter.net.il (MOS 3.5.8-GR) with ESMTP id BHD62238 (AUTH halo1); Sat, 21 May 2005 13:11:17 +0300 (IDT) Date: Sat, 21 May 2005 10:13:00 -0000 From: "Eli Zaretskii" To: fche@redhat.com Message-ID: <01c55ded$Blat.v2.4$11e9e260@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: drow@false.org, dan@shearer.org, gdb@sources.redhat.com In-reply-to: (fche@redhat.com) Subject: Re: [discuss] Support for reverse-execution Reply-to: Eli Zaretskii References: <20050516174649.GM19642@erizo.shearer.org> <20050520181515.GC2499@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00259.txt.bz2 > 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?