From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20624 invoked by alias); 7 Sep 2009 08:13:45 -0000 Received: (qmail 20606 invoked by uid 22791); 7 Sep 2009 08:13:42 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from smarthost01.mail.zen.net.uk (HELO smarthost01.mail.zen.net.uk) (212.23.3.140) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Sep 2009 08:13:32 +0000 Received: from [82.69.137.158] (helo=[10.17.20.102]) by smarthost01.mail.zen.net.uk with esmtp (Exim 4.63) (envelope-from ) id 1MkZLr-0006XT-PF; Mon, 07 Sep 2009 08:13:28 +0000 Message-ID: <4AA4C0A4.7000509@undo-software.com> Date: Mon, 07 Sep 2009 08:13:00 -0000 From: Greg Law User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 MIME-Version: 1.0 To: Jakob Engblom CC: 'Michael Snyder' , gdb@sourceware.org, 'Julian Smith' 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> <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> <005201ca2f8b$23c4cc60$6b4e6520$@com> In-Reply-To: <005201ca2f8b$23c4cc60$6b4e6520$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Smarthost01-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-09/txt/msg00112.txt.bz2 On 09/07/2009 08:16 AM, Jakob Engblom wrote: > >> 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... Intriguing. In what ways? We currently have a somewhat baroque bunch of python that wraps up gdb to enable our reverse debugging commands on users system where they've an older version of gdb installed. This includes some commands to display the current time and jump to an arbitrary time (where time is a scalar 64-bit integer). The rest of gdb remains blissfully unaware (obviously, since it's unpatched). I can see how in general "teaching" the concept of time to gdb would be a huge job. But I don't think a command to jump around arbitrarily and another to display the "current" time needs to teach anything about time to the rest of gdb. > > 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. All of the above sounds good to me. However, I still reckon a pair or commands simply to get and set the time as a scalar value should be both useful for the user, and trivial to implement (he said, confidently :-) It could be orthogonal to bookmarks (a way to convert bookmarks to scalar time value would be useful, but not essential to start with). We should probably pipe up with some patches, but I'm just slightly nervous that I may have missed something, especially as I'm not really terribly au fait with gdb's internals and its assumptions (hence the discussion first). Cheers, Greg -- Greg Law, Undo Software http://undo-software.com/