From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30905 invoked by alias); 21 May 2008 18:11:03 -0000 Received: (qmail 30598 invoked by uid 22791); 21 May 2008 18:11:00 -0000 X-Spam-Check-By: sourceware.org Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 21 May 2008 18:10:42 +0000 Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) by bluesmobile.specifix.com (Postfix) with ESMTP id A719A3C38E; Wed, 21 May 2008 11:10:40 -0700 (PDT) Subject: Re: GDB record patch 0.1.3.1 for GDB-6.8 release From: Michael Snyder To: Tea Cc: Thiago Jung Bauermann , gdb-patches@sourceware.org In-Reply-To: References: <1211231955.32587.23.camel@localhost.localdomain> Content-Type: text/plain Date: Wed, 21 May 2008 22:01:00 -0000 Message-Id: <1211393440.3601.80.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00643.txt.bz2 On Wed, 2008-05-21 at 16:54 +0800, Tea wrote: > > > - A question: if you record changes, then reverse GDB through them but > > stop it half-way, and then set the direction (gear? :-) ) back to > > forward, GDB will just play back the changes it has recorded, and not > > continue the inferior until it reaches the end of the record list, > > right? > > > > Yes, it's right. > > > If so this means that if the user goes back a few insns, modifies a > > variable which is used in an if condition, the code will still appear > > to take the branch it took before. This is unintuitive and may lead > > the inferior to an undefined state, impossible to achieve by regular > > runs of the program. So I think GDB either needs to be put in a > > "read-only" mode where it refuses to change inferior memory and > > registers, or it needs to discard the records made after the point > > where the change in inferior state was made. What do you think? > > > I think this is a bug of record. I will fix it. Once you get into the idea of going backward, you soon reach the idea of forking or branching -- taking a different route forward than you did originally. For an early implementation of reverse debugging, it would be fair to simply prohibit this -- don't let gdb change the machine state until you exit replay mode. If you want to get fancier, you could say that if the user does anything to change the recorded machine state, you automatically cancel replay mode and resume debugging a "live" machine from the new, changed state. If you want to improve on that a little bit more, you might say "If you change the machine state in the middle of a replay, I will throw away all of the recorded state *forward* of that point, but keep the recorded state going *back* from there. You can't go back into what used to be the "future" because by changing the past, you have now destroyed that particular future. But you can still go further into the past.