From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11705 invoked by alias); 20 Oct 2008 08:11:33 -0000 Received: (qmail 11697 invoked by uid 22791); 20 Oct 2008 08:11:32 -0000 X-Spam-Check-By: sourceware.org Received: from ey-out-1920.google.com (HELO ey-out-1920.google.com) (74.125.78.147) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 20 Oct 2008 08:10:57 +0000 Received: by ey-out-1920.google.com with SMTP id 4so499897eyg.24 for ; Mon, 20 Oct 2008 01:10:52 -0700 (PDT) Received: by 10.210.34.2 with SMTP id h2mr8396287ebh.82.1224490252884; Mon, 20 Oct 2008 01:10:52 -0700 (PDT) Received: by 10.210.44.8 with HTTP; Mon, 20 Oct 2008 01:10:52 -0700 (PDT) Message-ID: <87d3b2040810200110x714f8888ybbfd492da49eb2ee@mail.gmail.com> Date: Mon, 20 Oct 2008 08:11:00 -0000 From: "Frederic Riss" To: "Michael Snyder" Subject: Re: [discuss] semantics, "replay debugging" vs. "reverse debugging" Cc: gdb@sourceware.org In-Reply-To: <48FBDA34.6020104@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48FBDA34.6020104@vmware.com> 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: 2008-10/txt/msg00072.txt.bz2 Hello, 2008/10/20 Michael Snyder : > Just to make sure we're all on the same page, > I'm gonna state what I believe is true, and invite > discussion or contradiction. > > Replay debugging --> ability to record an execution > sequence and "play it back" (repeat it) with some > degree of determinism. > > Reverse debugging --> ability to make the inferior > process "back up" to a previous state, eg. reverse > step and reverse continue-to-breakpoint. > > They're related but not identical. One could theoretically > have one without the other, although in practice all > presently existing reverse-debug targets (that I know of) > are implemented by using record and replay. For what it's worth, I spent some evenings a few weeks ago starting a remote reversible gdbserver implementation as a valgrind skin. I've the 'record' part nearly done, but I've stopped working on it due to personal priorities inversion. My idea was that I'd use the recorded history to reverse the execution, but that I'd let the virtual processor do the replay itself (ie. simply let the target run form the state I would have restored). Of course, I was aware that some syscalls aren't 'reversible' and I was wondering how to report that to the user. My first idea was to just say: "You're using reverse debugging, watch your steps!". I see that 'replaying' the history can be useful in such cases, and I could certainly implement that on top of my history record. However, now I'm wondering: can't the current implementations 'rewrite the past'? My scheme of record->reverse->rerun was expected to allow the user to modify thing in the past execution and then watch the consequences. If it's possible for them, where is the decision made when to switch between replay and rerun? Take the above with a grain of salt, as I haven't worked on that project for quite some time, and I haven't yet implemented the reverse/rerun part. Fred. > One could have reverse without record/replay if, > for instance, one had a machine architecture where > all instructions were reversable, ie. the machine > itself could reverse-execute an instruction. > > And an example of a record/replay implementation > without reverse debugging capability would be > Michael Chastain's (circa 1999) implementation > of Linux system-call based record and replay, which > could deterministically replay a recorded program > execution, but did not have reverse-step or > reverse-continue-to-breakpoint. >