From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29343 invoked by alias); 21 May 2005 14:19:53 -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 29310 invoked from network); 21 May 2005 14:19:43 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 21 May 2005 14:19:43 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DZUp9-000097-NL; Sat, 21 May 2005 10:19:31 -0400 Date: Sat, 21 May 2005 14:19:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com Subject: Re: [discuss] Support for reverse-execution Message-ID: <20050521141931.GA430@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com References: <20050516174649.GM19642@erizo.shearer.org> <20050520181515.GC2499@nevyn.them.org> <01c55ded$Blat.v2.4$11e9e260@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c55ded$Blat.v2.4$11e9e260@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00264.txt.bz2 On Sat, May 21, 2005 at 01:07:41PM +0300, Eli Zaretskii wrote: > 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. Two things. One, it requires extensive additional support from the target. State is huge and complicated - multiple threads, file system operations, network packets. You need a target that supports checkpointing to do this. I'm told there are native platforms which could offer this - I just don't know what any of them are. Two, this is basically the same thing as the bookmarking feature already proposed in this thread; just have GDB automatically take a bookmark at every stop. > 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. Not at all. Here's a big use of reversible debugging: timing-sensitive or otherwise very hard-to-reproduce problems. You want to be able to leave the program running, hooked up to a simulator and a debugger, and then once the mysterious bug has occurred back up a little bit to see why. And the only way that checkpointing could be as user-friendly as stepping would be if GDB emulated the latter on the former, I think (already suggested). > How would this suggestion of mine map to the remote targets and > simulators that support checkpointing on the target side? Just fine, all it needs is bookmarking. -- Daniel Jacobowitz CodeSourcery, LLC