From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8635 invoked by alias); 7 Sep 2009 07:16:53 -0000 Received: (qmail 8615 invoked by uid 22791); 7 Sep 2009 07:16:48 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from dns.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Sep 2009 07:16:38 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 15A4F26EE4A; Mon, 7 Sep 2009 09:16:36 +0200 (CEST) Received: from polhem (unknown [62.20.90.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id DC45026EE40; Mon, 7 Sep 2009 09:16:35 +0200 (CEST) From: "Jakob Engblom" To: "'Greg Law'" Cc: "'Michael Snyder'" , , "'Julian Smith'" 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> <4A9BF84F.3070404@undo-software.com> <025201ca2ace$a9256430$fb702c90$@com> <4A9D2650.6080209@undo-software.com> <019501ca2ccb$0bc1bd70$23453850$@com> <4AA10B93.4000905@undo-software.com> In-Reply-To: <4AA10B93.4000905@undo-software.com> Subject: RE: Simics & reverse execution Date: Mon, 07 Sep 2009 07:16:00 -0000 Message-ID: <005201ca2f8b$23c4cc60$6b4e6520$@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-09/txt/msg00111.txt.bz2 > Example - say the user wants to go back to the beginning of time, but > didn't think to take a bookmark when they were there. Executing > backwards might take a long time. For systems like Simics, UndoDB and > VMware that use a snapshot-and-replay technique it can be almost instant > to jump back to time 0. We could always add a special command to goto > time 0 or a special bookmark, but why not generalise it? e.g. maybe the > user wants to skip forwards a few seconds' worth, but again, doesn't > have a bookmark conveniently placed. > > It seems that for at least some targets this would be pretty > straightforward to implement and a very useful feature for users. I agree with this, and I think that a notion of scalar time in some undefined unit would make the UI on the gdb side much easier. Problem is that gdb currently lacks a time concept... and my understanding is that introducing it is going to be painful. Time really becomes very pervasive once you start using it in one place... So, currently, a bookmarks mechanism seems to make the most sense. I think that most of the issues we have can be solved at the user-level: * Always take a bookmark when you start (which normally for is not time zero, but rather some arbitrary point in time of the target system when the reverse is turned on). * Allows the backend to push bookmarks. In that way, you just set up a script or module that sends bookmarks to gdb at a regular pace in target time (say every 1 microsecond on the target side or whatever). * Your frontend scripts can then rely on these bookmarks. Not super-solid, but it works with a simple bookmark mechanism and keeps time internal to the backend. /jakob