From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8223 invoked by alias); 26 Oct 2009 03:12:00 -0000 Received: (qmail 8213 invoked by uid 22791); 26 Oct 2009 03:11:58 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,SARE_MSGID_LONG40,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail-pz0-f189.google.com (HELO mail-pz0-f189.google.com) (209.85.222.189) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 26 Oct 2009 03:11:54 +0000 Received: by pzk27 with SMTP id 27so5384341pzk.12 for ; Sun, 25 Oct 2009 20:11:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.21.33 with SMTP id y33mr1019591wfi.174.1256526713132; Sun, 25 Oct 2009 20:11:53 -0700 (PDT) In-Reply-To: <4ADE1824.8090701@vmware.com> References: <4ADA4BD8.6080800@vmware.com> <4ADCAD14.3080407@vmware.com> <4ADE1824.8090701@vmware.com> From: Hui Zhu Date: Mon, 26 Oct 2009 07:54:00 -0000 Message-ID: Subject: Re: [FYI] tutorial for process record and reverse debugging To: Michael Snyder Cc: Marc Khouzam , "gdb@sourceware.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00370.txt.bz2 On Wed, Oct 21, 2009 at 04:05, Michael Snyder wrote: > Marc Khouzam wrote: > >>> OK, so good discussion. =A0Let's cover some bases here. >>> >>> 1) I'm in record mode, and I want to stay in record mode. >>> No brainer -- that's the default behavior. >>> >>> 2) I'm in record mode, and I want to go to replay mode. >>> Currently the only way to do that is to give a "reverse" >>> command (reverse step, reverse continue...) >>> >>> That's not too bad, but sometimes I might want to simply >>> go to the beginning of the log and start replaying forward >>> from the beginning (ie. not backwards from the end. >>> Or, I might even want to goto the middle before I start >>> to replay (in either direction). >>> >>> We can do that now by using breakpoints, but we might have >>> to disable other breakpoints, if there are any. >> >> And for long executions, jumping in the recorded log is probably >> faster than using breakpoints. =A0I agree that this seem valuable. >> >>> But we COULD do it if we had a command like "goto beginning", >>> or "goto bookmark 12". >> >> Again, this seems neat. =A0I do think it is somewhat of an >> 'advanced' feature, as it requires more understanding of PRecord >> than using breakpoints and reverse-continue/reverse-step/etc >> >>> 3) I'm in replay mode, possibly in the middle of the recording, >>> and I want to switch to record mode. =A0Now there are several >>> branching possibilities: =A0Do I want to: >>> >>> =A0 a) Go to the end and start appending to the existing log? >> >> I can understand someone wanting this. >> >>> =A0 b) Truncate the existing log at the point where I am, and >>> =A0 =A0 =A0start appending to the prefix? >> >> I never thought of this case. =A0I see now that for non-deterministic >> executions this could have value. > > Not just that, though. =A0This is also what happens if we > change a memory or register value, eg. a variable that > controls a conditional branch. =A0We auto-delete the trailing > part of the execution log, because now we're going to go > forward in a different direction. > > >>> =A0 c) Discard the existing log and start a new log from the >>> =A0 =A0 =A0point where I am? >> >> I think this one is simply to re-issue the 'record' command. >> Also, besides saving some space, I don't really see a big value >> compared to point b) above. > > It's a minor case (because it's easy). =A0I'm just being > exhaustive. > > [...] >> >> Now, let me describe the case I am imagining. >> It is as simple as it gets. >> The user simply enables the 'reverse debugging' feature. >> After that, the user should not need to pay attention to >> record logs and such. =A0What they should see is that they >> can go forward or backwards as if everything was true 'execution'. >> We don't need to differentiate between 'execution' and 'replay'. >> >> For example, when changing memory, the user doesn't need to know >> that we are moving away from replay into a new execution. =A0All they se= e is >> that the program moves forward with the new memory >> value. >> >> And that is why, in this scenario, I thought it seemed >> unintuitive to stop execution when >> arriving at the end of the replay log; instead, the user >> pressed 'continue' and the 'execution' should continue until >> a breakpoint or the end of the program, as if a true execution. >> >> The only limitation to this, is that we cannot go backwards >> past the start of the recording. =A0But I think this can be easily >> understood by the user. >> >> I don't think this scenario is good for everyone, but I think >> for average users, it makes reverse debugging very fluid. > > I think that's a great scenario -- just not the only scenario. > We could call that Marc-mode, for devel purposes. =A0 ;-) > > How would you suggest we might turn on Marc-mode with a > single command? > > Or do you imagine it being the default? > > For current status, this record still have a lot of limit. I think make it to default is not very fit for the current record. Thanks, Hui