From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3104 invoked by alias); 20 Oct 2009 20:12:21 -0000 Received: (qmail 3094 invoked by uid 22791); 20 Oct 2009 20:12:20 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-1.vmware.com (HELO smtp-outbound-1.vmware.com) (65.115.85.69) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Oct 2009 20:12:16 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 55EAC48016; Tue, 20 Oct 2009 13:12:15 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost3.vmware.com (Postfix) with ESMTP id 421ACCD9F0; Tue, 20 Oct 2009 13:12:15 -0700 (PDT) Message-ID: <4ADE1824.8090701@vmware.com> Date: Tue, 20 Oct 2009 21:01:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Marc Khouzam CC: 'Hui Zhu' , "'gdb@sourceware.org'" Subject: Re: [FYI] tutorial for process record and reverse debugging References: <4ADA4BD8.6080800@vmware.com> <4ADCAD14.3080407@vmware.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00323.txt.bz2 Marc Khouzam wrote: >> OK, so good discussion. Let'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. I 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. I 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. Now there are several >> branching possibilities: Do I want to: >> >> a) Go to the end and start appending to the existing log? > > I can understand someone wanting this. > >> b) Truncate the existing log at the point where I am, and >> start appending to the prefix? > > I never thought of this case. I see now that for non-deterministic > executions this could have value. Not just that, though. This is also what happens if we change a memory or register value, eg. a variable that controls a conditional branch. We auto-delete the trailing part of the execution log, because now we're going to go forward in a different direction. >> c) Discard the existing log and start a new log from the >> point 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). I'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. What 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. All > they see 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. But 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. ;-) How would you suggest we might turn on Marc-mode with a single command? Or do you imagine it being the default?