From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17719 invoked by alias); 21 Oct 2009 15:06:04 -0000 Received: (qmail 17709 invoked by uid 22791); 21 Oct 2009 15:06:03 -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; Wed, 21 Oct 2009 15:05:55 +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 n9LF5nkw005349; Wed, 21 Oct 2009 10:05:50 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.56]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:05:02 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 10:05:02 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.110]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 21 Oct 2009 11:05:01 -0400 From: Marc Khouzam To: "'Greg Law'" , "'Michael Snyder'" CC: "'Hui Zhu'" , "'gdb@sourceware.org'" Date: Wed, 21 Oct 2009 15:40:00 -0000 Subject: RE: [FYI] tutorial for process record and reverse debugging Message-ID: References: <4ADA4BD8.6080800@vmware.com> <4ADCAD14.3080407@vmware.com> <4ADE1824.8090701@vmware.com> <4ADE2502.5060201@undo-software.com> In-Reply-To: <4ADE2502.5060201@undo-software.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/msg00336.txt.bz2 =20 > -----Original Message----- > From: Greg Law [mailto:glaw@undo-software.com]=20 > Sent: Tuesday, October 20, 2009 5:01 PM > To: Michael Snyder > Cc: Marc Khouzam; 'Hui Zhu'; 'gdb@sourceware.org' > Subject: Re: [FYI] tutorial for process record and reverse debugging >=20 > Michael Snyder wrote: > > [...] > >> > >>> 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. > >=20 > > 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. >=20 > But what would we do about "external state"? >=20 > Example, say I'm debugging a web-server, and half way through a=20 > connection I go back, then truncate the log and start again in a new=20 > direction. And clients "mid-session" with the webserver are=20 > liable to=20 > get mighty confused. To be honest, I hadn't been dealing with any "external state" much. But now that you mention it, yes, that would make "auto-mode" (going from replay to record automatically) confusing. See below please. =20 > > [...] > >> 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.=20=20 > All they=20 > >> 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. > >=20 > > I think that's a great scenario -- just not the only scenario. > > We could call that Marc-mode, for devel purposes. ;-) > >=20 > > How would you suggest we might turn on Marc-mode with a > > single command? > >=20 > > Or do you imagine it being the default? > >=20 >=20 > FWIW, early versions of UndoDB operated in "Marc-mode". We=20 > changed it=20 > because replay mode and record are quite different,=20 > particularly w.r.t.=20 > to the program's interaction with the outside world. "Silent"=20 > transition=20 > from replay to record mode could be quite confusing/surprising. In cases where the program does interact with the outside world,=20 I agree that "auto-mode" could be confusing. In fact, "record mode" may not be the one we want in this case either. For instance, in some cases I may want to re-execute instructions that affect the outside world, even if I'm gone backwards. In this case I would want to use the recorded data to go backwards, but never to go forward (never use "replay mode"). This is giving me two ideas: 1- the frontend (my problem) would benefit in showing to the user if we are currently "executing" or "replaying". some minimal support from GDB would help there. 2- we could define a set of behaviors or modes for these scenarios record mode auto record mode replay record mode execute ... Thanks Marc