From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24355 invoked by alias); 21 May 2005 17:43:42 -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 24341 invoked by uid 22791); 21 May 2005 17:43:37 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 21 May 2005 17:43:37 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DZY0a-0001MF-O3; Sat, 21 May 2005 13:43:32 -0400 Date: Sat, 21 May 2005 17:43: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: <20050521174332.GA5140@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> <20050521141931.GA430@nevyn.them.org> <01c55e1b$Blat.v2.4$99652dc0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c55e1b$Blat.v2.4$99652dc0@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00272.txt.bz2 On Sat, May 21, 2005 at 06:40:45PM +0300, Eli Zaretskii wrote: > > Date: Sat, 21 May 2005 10:19:31 -0400 > > From: Daniel Jacobowitz > > Cc: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com > > > > 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. > > Well, at least the Linux kernel developers could perhaps be persuaded > to add such a support. Maybe. It would be a major piece of surgery; I think that checkpointing has been implemented before, but never merged. > > 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. > > Correct. What I'm saying is that by adding this we would provide a > large part of user-level functionality that is served by the full set > of reverse-* commands, but with the advantages that: > > (a) the list of new commands is much smaller and thus simpler > (b) we don't need to figure out the right semantics of tricky > commands like "reverse-next" and "reverse-finish" But the new commands would be much less useful. To me, at least. Why should we choose a lesser solution just to avoid figuring out the complicated bits of a more thorough solution? > (c) part of the implementation is on the GDB side (as opoosed to the > target side), so it will be easier to enable it for more targets (c) is Paul's and Frank's point. I think that it should wait until there's a target that doesn't provide it on the target side; I don't see a problem in using it if it's available. > > 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. > > Okay so perhaps it's less than 99%, but it's still a large portion. Well I can't (yet!) speak from experience, but I think that you're leaving out the most useful bits. -- Daniel Jacobowitz CodeSourcery, LLC