From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23448 invoked by alias); 21 May 2005 15:46:03 -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 23344 invoked from network); 21 May 2005 15:45:55 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 21 May 2005 15:45: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 BHF09388 (AUTH halo1); Sat, 21 May 2005 18:44:25 +0300 (IDT) Date: Sat, 21 May 2005 15:46:00 -0000 From: "Eli Zaretskii" To: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com Message-ID: <01c55e1b$Blat.v2.4$99652dc0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050521141931.GA430@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 21 May 2005 10:19:31 -0400) Subject: Re: [discuss] Support for reverse-execution Reply-to: Eli Zaretskii References: <20050516174649.GM19642@erizo.shearer.org> <20050520181515.GC2499@nevyn.them.org> <01c55ded$Blat.v2.4$11e9e260@zahav.net.il> <20050521141931.GA430@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00269.txt.bz2 > 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. > 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" (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 > > 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. Okay so perhaps it's less than 99%, but it's still a large portion.