From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19693 invoked by alias); 26 Oct 2009 01:12:05 -0000 Received: (qmail 19684 invoked by uid 22791); 26 Oct 2009 01:12:05 -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; Mon, 26 Oct 2009 01:12:01 +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 n9Q1Bu2H019346; Sun, 25 Oct 2009 20:11:56 -0500 Received: from eusrcmw751.eamcs.ericsson.se ([138.85.77.51]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 20:11:30 -0500 Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Oct 2009 20:11:30 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.4]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Sun, 25 Oct 2009 21:11:29 -0400 From: Marc Khouzam To: Greg Law CC: "'Michael Snyder'" , "'Hui Zhu'" , "'gdb@sourceware.org'" Date: Mon, 26 Oct 2009 03:05: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> <4AE34766.9060305@undo-software.com> In-Reply-To: <4AE34766.9060305@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/msg00368.txt.bz2 > I'm not completely sure of the behaviour of process record here, but > UndoDB in replay mode is completely "neutered", in that the results of > all system calls are 'synthesised'. So if, say, in record mode your > program unlinks a file, then in replay mode the fact the=20 > filename is no > longer present on the filesystem doesn't matter - we don't=20 > really do an=20 > unlink, we just replay the results of whatever unlink=20 > returned when in=20 > record mode. >=20 > I *believe* process record does the same, as would any reasonably sane > reversible debugging approach. If you can step back over an > instruction, you do so without actually executing the instructions in > question. So it seems reasonable that in replay mode you can=20 > also step > forwards, but without actually executing the instruction. I just wanted to clarify what I meant. I agree with you that the behavior you describe is probably the most useful one. But I was thinking of certain cases, most probably very rare, such as: I have a client/server setup where my server answers simple queries; when running the client in the debugger I would find it useful to execute the sending of a query, then go backwards and (intead of replaying "neutered") go forwards again and re-send the query. The idea here is that I'm more testing my server than my client by doing this. Granted, this example is pretty simplistic and probably not that useful, but I just thought it illustrated that some users may want to not use replay but instead re-execute. So it may be nice to have a command to do that, or a 'mode' that always did that. Marc