From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22714 invoked by alias); 27 Aug 2009 17:56:17 -0000 Received: (qmail 22700 invoked by uid 22791); 27 Aug 2009 17:56:16 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 27 Aug 2009 17:56:12 +0000 Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 91BBA37006; Thu, 27 Aug 2009 10:56:10 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by jupiter.vmware.com (Postfix) with ESMTP id 873E9DC059; Thu, 27 Aug 2009 10:56:10 -0700 (PDT) Message-ID: <4A96C8E4.5050905@vmware.com> Date: Fri, 28 Aug 2009 11:04:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Jakob Engblom CC: "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> <01fc01ca26ed$b0a63e30$11f2ba90$@com> In-Reply-To: <01fc01ca26ed$b0a63e30$11f2ba90$@com> Content-Type: text/plain; charset=us-ascii; format=flowed 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/msg00263.txt.bz2 Jakob Engblom 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? > > 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. I think we're saying the same thing. GDB doesn't know anything about logical clocks. The target (simics/process record/vmware/whoever) can give gdb an arbitrary piece of data to represent a bookmark, and gdb can give it back again later. For Simics, it may be a timestamp or logical clock. For process record, I think it would be an instruction count. GDB should not care what it is. We just need to decide on a data protocol representation for it. For a UI, we just need to present a list to the user, something like we do for breakpoints. Each bookmark (checkpoint?) can be identified by a small counting integer, and then maybe some target-specific description such as we do for threads (where the target has a callback for presenting "thread info" in a user-readable way).