From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24597 invoked by alias); 20 Oct 2009 00:59:21 -0000 Received: (qmail 24299 invoked by uid 22791); 20 Oct 2009 00:59:19 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from imr2.ericy.com (HELO imr2.ericy.com) (198.24.6.3) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Oct 2009 00:59:14 +0000 Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n9K0xCWh012999; Mon, 19 Oct 2009 19:59:12 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 19:58:24 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 19:58:23 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.110]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Mon, 19 Oct 2009 20:58:23 -0400 From: Marc Khouzam To: Michael Snyder CC: "'Hui Zhu'" , "'gdb@sourceware.org'" Date: Tue, 20 Oct 2009 06:44:00 -0000 Subject: RE: [FYI] tutorial for process record and reverse debugging Message-ID: References: <4ADA4BD8.6080800@vmware.com> <4ADCAD14.3080407@vmware.com> In-Reply-To: <4ADCAD14.3080407@vmware.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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/msg00311.txt.bz2 =20 > (gdb) record goto end > (gdb) record goto beginning > (gdb) record goto instruction 12345 > (gdb) record goto bookmark 7 >=20 > Easy enough to make this command ignore breakpoints watchpoints etc. This sounds neat. Seems like it has a lot of potential. =20 > > In the tutorial, around the middle of section=20 > > "Continue, reverse-continue, and breakpoints" > > it mentions that after doing some reverse execution, we may be > > "now ready to resume where we left off". > >=20 > > From what I understand this means that the user may decide that she > > is done with reverse execution and wants to go back to executing > > the live program. To do this, we need to disable all bps, do a > > 'continue' and then (optionally) re-enable all bps. > >=20 > > If going straight to the end of the recording log is a valuable > > feature, I was thinking it may deserve its own command. > >=20 > > Ultimately, I'm hoping that with such a command, we can then see > > if we can have PRecord directly jump from recorded execution > > to live execution without stopping. > >=20 > > I'm hoping to get opinions from you experts, as I'm not sure it is > > a good idea. >=20 > OK, so good discussion. Let's cover some bases here. >=20 > 1) I'm in record mode, and I want to stay in record mode. > No brainer -- that's the default behavior. >=20 > 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...) >=20 > 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). >=20 > 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: >=20 > 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. > 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. > d) Go back to the beginning, discard the existing log, and > start a new log from the beginning? I think this is run record In Eclipse we have a 'restart' button that calls the 'run' command and we have a way to automatically turn on 'record' if the user wants. So that is one feature the frontend can do without gdb support (I don't believe that is the case for any other scenarios you brought up). =20 > These are all things that I think we can do at present, but > not generally with a single command. Maybe we should kick > them around. They're all useful, and not far out of reach. > They wouldn't, for instance, require that we keep several > branching logs around at the same time (although just think > what would be possible if we could do that!!! ) Wow, that would be something to see. The UI stuff might be tricky though. 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=20 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. Thoughts? Marc