From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20575 invoked by alias); 28 Aug 2009 11:04:54 -0000 Received: (qmail 20566 invoked by uid 22791); 28 Aug 2009 11:04:53 -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; Fri, 28 Aug 2009 11:04:46 +0000 Received: from [82.69.137.158] (helo=[10.17.20.102]) by smarthost02.mail.zen.net.uk with esmtp (Exim 4.63) (envelope-from ) id 1MgzG6-0001N1-55; Fri, 28 Aug 2009 11:04:42 +0000 Message-ID: <4A97B9C9.8070501@greglaw.net> Date: Fri, 28 Aug 2009 15:17:00 -0000 From: Greg Law User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Michael Snyder CC: Jakob Engblom , "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> In-Reply-To: <4A95E319.6020300@vmware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Smarthost02-IP: [82.69.137.158] 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/msg00264.txt.bz2 Hi, Michael Snyder wrote: > [...] > > I think we just need to come up with a sufficiently arbitrary > way to represent both a "point in time" and a "bookmark", so > that they can be passed back and forth between gdb and the > remote target without gdb needing to know what they actually > represent (eg. a timestamp or a branch count). Only the target > needs to know how to interpret them. > > Maybe an 8 byte integer would be sufficient? What do you think? As you know, we're currently putting together a remote target so that UndoDB can take advantage of gdb's new reverse debug support. (We hope to have something ready quite soon.) 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. 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? Cheers, Greg -- Greg Law, Undo Software http://undo-software.com/