From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5587 invoked by alias); 31 Aug 2009 16:20:48 -0000 Received: (qmail 5573 invoked by uid 22791); 31 Aug 2009 16:20:47 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from smarthost02.mail.zen.net.uk (HELO smarthost02.mail.zen.net.uk) (212.23.3.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 31 Aug 2009 16:20:40 +0000 Received: from [82.71.15.62] (helo=[192.168.123.106]) by smarthost02.mail.zen.net.uk with esmtp (Exim 4.63) (envelope-from ) id 1Mi9cQ-0002sH-Fz; Mon, 31 Aug 2009 16:20:34 +0000 Message-ID: <4A9BF84F.3070404@undo-software.com> Date: Mon, 31 Aug 2009 16:34:00 -0000 From: Greg Law User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Jakob Engblom CC: 'Michael Snyder' , gdb@sourceware.org Subject: Re: Simics & reverse execution 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> In-Reply-To: <010b01ca2a3c$7766ca70$66345f50$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Smarthost02-IP: [82.71.15.62] 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/msg00277.txt.bz2 Jakob Engblom wrote: >> 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? No, it's essentially a combination of pointers that we know will uniquely identify a point in history. > > 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. I guess my worry is that there would be some kind of ordering associated with the time values. That is, we could use such a mapping, as long as no one assumes that you can do an integer compare of two bookmarks or times to know whether one is "later" than the other. If the 64 bits of the integer were to be considered 'opaque' and no more than a unique handle onto a point in history, that would be fine. But such a restriction is unfortunate, because you wouldn't be able to e.g. binary chop history. Obviously, any opaque bag of bits is going to suffer like that. What we do currently in UndoDB is to have calls to get a relatively course grain linear, scalar integer value from an undodb_time_t. It's coarse-grained in that several close together but distinct points in history (e.g. adjacent instructions) may get the same scalar value, but in reality not many, and so it's enough to do binary chops, etc. Greg -- Greg Law, Undo Software http://undo-software.com/