From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6428 invoked by alias); 21 Oct 2008 07:27:28 -0000 Received: (qmail 6410 invoked by uid 22791); 21 Oct 2008 07:27:27 -0000 X-Spam-Check-By: sourceware.org Received: from dns.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Oct 2008 07:26:37 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 0895926EF07; Tue, 21 Oct 2008 09:26:34 +0200 (CEST) Received: from polhem (unknown [62.20.90.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id DAFC226EF06; Tue, 21 Oct 2008 09:26:33 +0200 (CEST) From: "Jakob Engblom" To: "'Michael Snyder'" , References: <48FBDA34.6020104@vmware.com> In-Reply-To: <48FBDA34.6020104@vmware.com> Subject: RE: [discuss] semantics, "replay debugging" vs. "reverse debugging" Date: Tue, 21 Oct 2008 07:27:00 -0000 Message-ID: <007d01c9334e$582141d0$0863c570$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-Language: sv 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/msg00078.txt.bz2 > 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. >=20 > Replay debugging --> ability to record an execution > sequence and "play it back" (repeat it) with some > degree of determinism. I think there are two very important different types of recording in existe= nce: * Complete CPU state tracing, like you get with the trace boxes from GreenH= ills and Lauterbach, for example. They have a limited reach as they as basically reusing a circular buffer, but the CPU execution can be replicated 100%. However, you can only work within the length of the recording. * Recording system execution at a higher level and then force the execution= path at important points, such as the Zealcore/Enea solutions. Here, you force = task switches and asynch IO to occur at certain points, and hope that the system underneath is deterministic enough that you see the same code execution.=20 I am not familiar with gdb process recording, I would assume it goes into t= he first category, but running on ahost rather than using JTAG/etc. > Reverse debugging --> ability to make the inferior > process "back up" to a previous state, eg. reverse > step and reverse continue-to-breakpoint. Sounds good.=20 > 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. Well, depends on how you do the recording... what you need is some way to reconstruct thee previous state in a consistent manner. This can be done in= a few ways: * Complete recording, as above * Completely deterministic target, where you can reset to start, and then j= ust reexecute until the point of interest. Requires a controlled world that ha= s no asynch inputs. For example, booting a machien inside a full-system simulat= or works like this most of the time (if you script all serial inputs needed, a= nd provide simulation models for network services). Simics does this with eas= e, for example. It does require that the simulation system complete imposes semantics on all timed events, which is the case in most cases.=20 * Deterministic target with recording of asynch IO. This is what Simics do= es when a simulated set of machines is connected to a physical network connect= ion or subject to unscripted user input.=20=20 > 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. Not particularly likely, though? Most machine instructions destroy informat= ion, like XOR R0,R0... > 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. Sounds like my recording type 2 above, actually.=20 Best regards, /jakob _______________________________________________________ Jakob Engblom, PhD, Technical Marketing Manager Virtutech Direct: +46 8 690 07 47=20=20=20=20 Drottningholmsv=E4gen 14 Mobile: +46 709 242 646=20=20=20 11243 Stockholm Web: www.virtutech.com=20=20 Sweden ________________________________________________________ =20