From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30373 invoked by alias); 31 Aug 2009 13:10:58 -0000 Received: (qmail 30365 invoked by uid 22791); 31 Aug 2009 13:10:57 -0000 X-SWARE-Spam-Status: No, hits=-1.9 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; Mon, 31 Aug 2009 13:10:52 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 0C64E26EF82; Mon, 31 Aug 2009 15:10:50 +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 DE36326EF45; Mon, 31 Aug 2009 15:10:49 +0200 (CEST) From: "Jakob Engblom" To: "'Greg Law'" , "'Michael Snyder'" Cc: 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> In-Reply-To: <4A97B9C9.8070501@greglaw.net> Subject: RE: Simics & reverse execution Date: Mon, 31 Aug 2009 13:22:00 -0000 Message-ID: <010b01ca2a3c$7766ca70$66345f50$@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-08/txt/msg00273.txt.bz2 > Anyway, 8-bytes is not a sufficiently general representation of time for > UndoDB. The trouble is, we don't keep a linear cycle count or such like. > We could in theory, but it would slow us down. So instead we > represent time as a structure. What exactly is represented here? Some kind of tree of execution? If it is a linear execution, couldn't you just map arbitrary points in time to integers? Also, note that as Michael says, the idea here is to have an ID number that passes back and forth between gdb and the target, which is then resolved at the target. > So, I think it would be better if the abstract time representation could > be an opaque "bag of bits" of arbitrary size. > > We'd be happy to contribute some patches along these lines, although I > don't think we'd be able to do anything in time for the proposed gdb 7 > branch. > > What do people think? I think it might be unnecessary: unless you need more than 2^64 distinct bookmarks/points in time tracked, can't you do a local map in your backend between gdb logical bookmark IDs and the internal time representation? Note in that in our case, the "time" is not really that simple... when you factor in multithreaded simulation of multiboard targets and temporal decoupling, Simics typically has ten different "points in time" active at the same time... but for reveexec, we untangle this for the benefit of the user. /jakob