From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3980 invoked by alias); 27 Aug 2009 01:35:45 -0000 Received: (qmail 3966 invoked by uid 22791); 27 Aug 2009 01:35:44 -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 01:35:37 +0000 Received: from mailhost3.vmware.com (mailhost3.vmware.com [10.16.27.45]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id AEFB62C00C; Wed, 26 Aug 2009 18:35:35 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost3.vmware.com (Postfix) with ESMTP id A6AFACD902; Wed, 26 Aug 2009 18:35:35 -0700 (PDT) Message-ID: <4A95E319.6020300@vmware.com> Date: Thu, 27 Aug 2009 04:44: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> In-Reply-To: <027701ca209f$64c71ce0$2e5556a0$@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/msg00254.txt.bz2 Jakob Engblom wrote: > Doing reverse breakpoints basically involves successively jumping back and > executing forward until breakpoints trigger. I think process record does > something very similar, based on the recording, right? No, that's one major difference with process-record. It doesn't use any state snapshots or checkpoints, its data contains only change sets for single instructions. So it executes backward one instruction at a time, in reverse sequence. Of course, to the user, and to the core of gdb, the difference is invisible, except possibly for speed. [...] > What this means for Simics and gdb remote is that it would be nice to be able to > deal with points in time: in Simics, you are moving the target system clock > around in time arbitrarily. In the Simics reverse interface, you can go to a > certain point in time, and also set execution bookmarks. Those are both very cool ideas, and I would like to add them, both to the remote protocol and to process remote. 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? So I'm thinking something like: 1) user to gdb: "I want to place a bookmark here (now)". 2) gdb to target: "Give me a marker that I can later use to mean "here (now)". 3) target to gdb: "Ok, here, use this instruction count." 4) (later): user to gdb: "I want to return to this bookmark". 5) gdb to target: "Please return to this marker that you gave me earlier".