From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24637 invoked by alias); 21 Oct 2009 14:55:45 -0000 Received: (qmail 24627 invoked by uid 22791); 21 Oct 2009 14:55:44 -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 imr1.ericy.com (HELO imr1.ericy.com) (198.24.6.9) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Oct 2009 14:55:40 +0000 Received: from eusrcmw750.eamcs.ericsson.se (eusrcmw750.exu.ericsson.se [138.85.77.50]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id n9LEtaQa024466; Wed, 21 Oct 2009 09:55:37 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.53]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:55:11 -0500 Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 09:55:10 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.110]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 21 Oct 2009 10:55:10 -0400 From: Marc Khouzam To: "'Michael Snyder'" CC: "'Hui Zhu'" , "'gdb@sourceware.org'" Date: Wed, 21 Oct 2009 15:06: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> In-Reply-To: <4ADE1824.8090701@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/msg00335.txt.bz2 =20 > -----Original Message----- > From: gdb-owner@sourceware.org=20 > [mailto:gdb-owner@sourceware.org] On Behalf Of Michael Snyder > Sent: Tuesday, October 20, 2009 4:06 PM > To: Marc Khouzam > Cc: 'Hui Zhu'; 'gdb@sourceware.org' > Subject: Re: [FYI] tutorial for process record and reverse debugging >=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'. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. ;-) Just so it doesn't go to my head, how about "auto-mode" as in "transitions from replay to record are done automatically" (and without querying the user). > How would you suggest we might turn on Marc-mode with a > single command? Maybe we can introduce a user setting such as "record mode " > Or do you imagine it being the default? Greg's follow-up email made me re-think a bit how intuitive auto-mode would be. I'll reply to his email with my comments. Marc