From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1518 invoked by alias); 3 Sep 2009 19:16:45 -0000 Received: (qmail 1508 invoked by uid 22791); 3 Sep 2009 19:16:45 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 03 Sep 2009 19:16:39 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 7EA6F26EF01; Thu, 3 Sep 2009 21:16:36 +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 5520F26EEE3; Thu, 3 Sep 2009 21:16:36 +0200 (CEST) From: "Jakob Engblom" To: "'Greg Law'" Cc: "'Michael Snyder'" , , "'Julian Smith'" References: <002001ca1f0e$4c9b74a0$e5d25de0$@com> <002101ca1f2e$746e1ad0$5d4a5070$@com> <200908171251.07179.pedro@codesourcery.com> <4A899E2E.6080203@vmware.com> <00b801ca1f74$e5610a90$b0231fb0$@com> <4A89B7E4.9010804@vmware.com> <027701ca209f$64c71ce0$2e5556a0$@com> <4A95E319.6020300@vmware.com> <4A97B9C9.8070501@greglaw.net> <010b01ca2a3c$7766ca70$66345f50$@com> <4A9BF84F.3070404@undo-software.com> <025201ca2ace$a9256430$fb702c90$@com> <4A9D2650.6080209@undo-software.com> In-Reply-To: <4A9D2650.6080209@undo-software.com> Subject: RE: Simics & reverse execution Date: Thu, 03 Sep 2009 19:16:00 -0000 Message-ID: <019501ca2ccb$0bc1bd70$23453850$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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-09/txt/msg00048.txt.bz2 > currently are (to allow e.g. a graphical frontend to implement a > slide-bar to show where in the record log we are). The former is > precise to instruction count (and signals, etc); the latter may not be > depending on the details of the target. Actually, percentage is the > wrong term -- better would be what fraction of the way are we through > history, e.g. in 1/(2^64) increments, such that half way through > recorded history would be represented as 2^63. I can see one big problem with this: you are assuming a bounded recording. In our case, it is unbounded (except for the current 64 bit counter of picoseconds used to coordinate all processors and other time-dependent parts in a simulation system, which bounds execution at an annoying 280 days of time). In Simics, you can always just continue past the end of the previously seen execution, and you extend the size of the reversible window. I believe VMWare does the same from my experiemtns with Workstation 6.5. I honestly think binary chop is best put into the backend for this reason... the times I have seen it applied it relied on large state-checking scripts running that had far better insight into the target system than you get with gdb (such as doing global consistency checks on the state of file systems on various boards in a fault-tolerant redundant cluster). /jakob