From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22832 invoked by alias); 24 Oct 2009 18:29:10 -0000 Received: (qmail 22821 invoked by uid 22791); 24 Oct 2009 18:29:09 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smarthost03.mail.zen.net.uk (HELO smarthost03.mail.zen.net.uk) (212.23.3.142) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 24 Oct 2009 18:29:03 +0000 Received: from [82.71.15.62] (helo=[192.168.123.72]) by smarthost03.mail.zen.net.uk with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1N1lMF-0003ph-Rj; Sat, 24 Oct 2009 18:28:56 +0000 Message-ID: <4AE34766.9060305@undo-software.com> Date: Sat, 24 Oct 2009 19:29:00 -0000 From: Greg Law User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Marc Khouzam CC: 'Greg Law' , 'Michael Snyder' , 'Hui Zhu' , "'gdb@sourceware.org'" Subject: Re: [FYI] tutorial for process record and reverse debugging References: <4ADA4BD8.6080800@vmware.com> <4ADCAD14.3080407@vmware.com> <4ADE1824.8090701@vmware.com> <4ADE2502.5060201@undo-software.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Smarthost03-IP: [82.71.15.62] 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/msg00355.txt.bz2 Marc Khouzam wrote: > > >> [...] >>> Or do you imagine it being the default? >>> >> FWIW, early versions of UndoDB operated in "Marc-mode". We changed >> it because replay mode and record are quite different, particularly >> w.r.t. to the program's interaction with the outside world. >> "Silent" transition from replay to record mode could be quite >> confusing/surprising. > > In cases where the program does interact with the outside world, 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"). 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 filename is no longer present on the filesystem doesn't matter - we don't really do an unlink, we just replay the results of whatever unlink returned when in record mode. 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 also step forwards, but without actually executing the instruction. > > 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. I agree this would be very useful for the user. > > 2- we could define a set of behaviors or modes for these scenarios > record mode auto record mode replay record mode execute ... Yes, that should work. I can see giving the user the ability to tweak it would help. I think the default should be to stop, but what the default is could always be overridden by the frontend. Greg -- Greg Law, Undo Software http://undo-software.com/