From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA03572; Mon, 26 Nov 2001 15:51:57 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA03564 for ; Mon, 26 Nov 2001 15:51:56 +0100 (MET) Received: from earth.cs.mu.oz.au (earth.cs.mu.OZ.AU [128.250.37.146]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id fAQEprX13506; Mon, 26 Nov 2001 15:51:54 +0100 (MET) Received: from fjh by earth.cs.mu.oz.au with local (Exim 3.32 #1 (Debian)) id 168N6s-0007y6-00; Tue, 27 Nov 2001 01:51:50 +1100 Date: Tue, 27 Nov 2001 01:51:50 +1100 From: Fergus Henderson To: Xavier Leroy Cc: Yoann Padioleau , caml-list@inria.fr Subject: Re: [Caml-list] replay debugger Message-ID: <20011127015149.A10358@earth.cs.mu.oz.au> References: <20011004143909.A16053@pauillac.inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011004143909.A16053@pauillac.inria.fr> User-Agent: Mutt/1.3.22i Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On 04-Oct-2001, Xavier Leroy wrote: > [The question was: how does the OCaml debugger implements reverse execution?] > > > Y'a t'il de la doc sur le fonctionnement interne du debuggger. > > Comment ca marche ? comment ki fait pour revenir en arriere ? > > Like all "time-travel" debuggers: by periodic checkpointing. I think that comment could be misleading. According to the Academic Press Dictionary of Science and Technology, "checkpoint" means | [...] Computer Programming. A designated point in a program where | processing is interrupted and all status information is recorded | in order to be able to restart the process at that point, thus | avoiding the necessity to repeat the processing from the beginning. So I think it would be reasonable to interpret Xavier's comment as meaning that you must periodically save the entire state of the program. But that's not how logic programming debuggers, such as those for Mercury and various Prolog implementations, do it. Rather than periodically checkpointing the entire state, these systems keep an incremental record of all destructive updates performed, on a separate stack called the "trail". On backtracking, the system will unwind the trail, restoring all the modified objects to their original values. Now, this may be a matter of terminology. I consider "checkpointing" and "trailing" to be two different ways of achieving the same result ("replay debugging", in this case, or more generally "roll-back capability"). But maybe Xavier had in mind a broader definition of "checkpointing", which would encompass trailing. > We learnt this trick from Andrew Tolmach's thesis: > http://www.cs.pdx.edu/~apt/thesis.ps.Z Looking at the details here [or at least those which show up on the first few pages -- after that, ghostview reports a Postscript error :-( ], it seems that the technique described here is actually much more similar to typical Prolog implementations than Ocaml's fork()-based implementation. In particular, Tolmach uses a "history log", which sounds like it would be pretty much identical to the Prolog trail, for recording updates to mutable data structures. -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. ------------------- Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr