From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31578 invoked by alias); 8 Sep 2009 19:11:30 -0000 Received: (qmail 31192 invoked by uid 22791); 8 Sep 2009 19:11:25 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from smarthost02.mail.zen.net.uk (HELO smarthost02.mail.zen.net.uk) (212.23.3.141) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Sep 2009 19:11:18 +0000 Received: from [82.71.15.62] (helo=[192.168.123.72]) by smarthost02.mail.zen.net.uk with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1Ml65y-0006Fh-VF; Tue, 08 Sep 2009 19:11:15 +0000 Message-ID: <4AA6AC52.4080808@undo-software.com> Date: Tue, 08 Sep 2009 19:11:00 -0000 From: Greg Law User-Agent: Thunderbird 2.0.0.23 (X11/20090817) 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> <4AA4C0A4.7000509@undo-software.com> <009b01ca2f94$9d6508b0$d82f1a10$@com> <4AA4F724.1050708@undo-software.com> <017001ca3054$f2d26020$d8772060$@com> <4AA64929.1040305@undo-software.com> <01c001ca3084$908f30c0$b1ad9240$@com> In-Reply-To: <01c001ca3084$908f30c0$b1ad9240$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Smarthost02-IP: [82.71.15.62] 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/msg00135.txt.bz2 Jakob Engblom wrote: >>> That's why an abstract bookmark concept is so appealing: it can hide > anything >> in >>> the backend, and let it worry about setting up times on multiple processors, >>> multiple machines, or hardware recorders. >> Ok, yes, I see what you're getting at here: bookmarks might be more >> easily implemented in some targets than some global linear notion of >> time. > > Not quite... but it lets us get some use out of time in gdb without introducing > a time concept. As I said, if we let the backend generate bookmarks, we can get > to any time precision we want by pushing bookmarks from the backend. Withtout > gdb having to understnad time. Ah, the discussion comes back to where we started :) Sincere apologies if I'm being stupid here, but I'm still struggling to understand you. i.e. I still don't understand why "get-time/set-time" commands require that gdb gains any notion of time. You mentioned earlier that a target might want routinely to generate bookmarks (e.g. every 10ms). If that target numbered those bookmarks 1,2,3,4,etc then it would have exactly the notion of time that I'm asking for here. > > Another issue with time is that once gdb knows about time, you have to be much > more careful when changing place in the program. If jumping back and forth, you > have to make sure that gdb time is correctly updated. Today, having a > state-less debugger makes this easier: we retrofitted (as I guess you did) > reverse execution on gdb quite easily since gdb had no notion of time. Had > there been that, it would have been much more painful. I don't follow. If we had "get-time/set-time" commands, these could be proxied by gdb straight to the target. Thus gdb remains stateless in this regard, and blissfully unaware of any notion of jumping around in time. All gdb needs to know is that "set-time" will change the target's state, but that's no different to regular continue or step. > >>>> Again, you could go a lot further than I'm proposing right now. But >>>> that's not to say you need to for this stuff be useful. >>> Yes, for us, a 64-bit integer count of time would be quite useful as a > general >>> tool. >> Cool - so is the general agreement that a scalar notion of time is a >> useful thing to add, even if it's not supported in all reversible >> targets? (And bookmarks is an (at least) equally useful notion.) > > I think a scalar time is very useful. But I fear that implementing it will meet > with resistance and require quite drastic changes. Bookmarks are probably > easier to introduce as a first step. That was what Michael Snyder said, and I > can agree with that. Hopefully Michael can clarify, but I thought he was agreeing that we don't want to teach gdb about the concept of time (not yet anyway), which I also totally agree with. My proposal is that a "timestamp" (i.e. what "get-time" returns) would be very like a "bookmark", except: (a) not precise like a bookmark (e.g. if "get-time" returns timestamp X, then a subsequent "set-time" will take you close to time X, but not necessarily exactly at time X) (b) multiple timestamps can be compared to get an approximate idea of their point in history relative to each other. e.g. timestamp 20 would come before 22 and 22 would come before 100, and also 22 is is much closer to 20 than it is to 100. > > Ideally, I DO want gdb to be time-aware, but that does require a lot of semantic > thinking for how time can and should interact with multiple threads, processor > cores, and reverse debug systems. Note my emphasis on "user" above - I'm not talking about gdb making any semantic interpretation of the timestamp. It's just a number that gdb displays to the user. Opaque to gdb, but potentially meaningful to the user. Greg -- Greg Law, Undo Software http://undo-software.com/