From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29345 invoked by alias); 27 Aug 2009 08:09:39 -0000 Received: (qmail 29321 invoked by uid 22791); 27 Aug 2009 08:09:38 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from oden.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Aug 2009 08:09:29 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id D6DD326EF3B; Thu, 27 Aug 2009 10:09:25 +0200 (CEST) Received: from polhem (79.138.197.134.bredband.tre.se [79.138.197.134]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id B172A26EF09; Thu, 27 Aug 2009 10:09:22 +0200 (CEST) From: "Jakob Engblom" To: "'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> In-Reply-To: <4A95E319.6020300@vmware.com> Subject: RE: Simics & reverse execution Date: Thu, 27 Aug 2009 08:17:00 -0000 Message-ID: <01fc01ca26ed$b0a63e30$11f2ba90$@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/msg00258.txt.bz2 > 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? I think a logical clock is the only sensible solution, actually, as you say, we cannot know the time. In Simics, we use cycle counts, and bookmarks are just names for a particular cycle count point. A good question is whether bookmarks should be part of state in gdb or in the backend or both. Obviously, there are nasty corner cases that are too complex for this protocol to handle. In particular, if you are using a temporally decoupled simulation engine where multiple processors are run for time slices before switching to the next, there is a minor chance that you can see time jump back and forth (local time on th current processor) as you execute logically forward... our tools handle that, but it is pretty hard to do right and I don't expect gdb to have to deal with that. Let the backends do it. /jakob