From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3400 invoked by alias); 17 Sep 2009 03:07:25 -0000 Received: (qmail 3391 invoked by uid 22791); 17 Sep 2009 03:07:24 -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, 17 Sep 2009 03:07:21 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 890AF22008; Wed, 16 Sep 2009 20:07:17 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by mailhost2.vmware.com (Postfix) with ESMTP id 69EE38E817; Wed, 16 Sep 2009 20:07:17 -0700 (PDT) Message-ID: <4AB1A7DD.4040803@vmware.com> Date: Thu, 17 Sep 2009 03:07:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Jakob Engblom CC: 'Greg Law' , "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> <4AA6AC52.4080808@undo-software.com> <013401ca3514$fa8b1f40$efa15dc0$@com> In-Reply-To: <013401ca3514$fa8b1f40$efa15dc0$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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/msg00221.txt.bz2 Jakob Engblom wrote: >>> 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. > > I think that is safe... but Michael Snyder was very clear that this had some > major issues as I understood it? What I think I said was that gdb doesn't currently have any knowledge about time, and that I don't believe it needs to (other than to do what you specifically want to do). >> 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. > > Yes, but it is done without any time representation at the gdb side of things. This is not what I had in mind when I said "bookmark". I can see the utility of this concept, but I'd rather call it something else to distinguish the two. The concept that I was thinking about as "bookmark" was a relatively small number of discrete points in the execution trace that gdb would keep track of in a list, in response to explicit, discrete user requests. Like breakpoints or checkpoints. Something that the target generates a large number of, automatically or at discrete intervals or something, sounds to me a little more similar to tracepoints. Maybe we could talk about using something a little more like tracepoint semantics for that. >> 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. > > Yes, but it does invite for time to become more part of the state. It's a hell of an interesting idea -- I can certainly understand why you're interested in it. But I don't think it's a requirement, for the simple concept of bookmarks. > > Note that I am all for this, but I can see how it quickly degenerates into a > major design issue with > > ""get-time -thread x" ... how is THAT done?" ... etc ... > >> 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. > > OK. All on the same plate. > >> 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) > > Interesting idea to make this fuzzy. I can see a problem with this: unless your > backend has its own UI where you CAN check the precise time, this invites user > confusion. I often find myself carefully stepping back and forth very precise > cycle counts to observer what is going on... and this fuzzy time would not let > me do that. It also means that when execution stops after a "set-time" command, > you really don't know where you are :) > > > Best regards, > > /jakob > > _______________________________________________________ > > Jakob Engblom, PhD, Technical Marketing Manager > > Virtutech Direct: +46 8 690 07 47 > Drottningholmsvägen 22 Mobile: +46 709 242 646 > 11243 Stockholm Web: www.virtutech.com > Sweden > ________________________________________________________ > > > /jakob > >