From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20852 invoked by alias); 8 Sep 2009 13:02:29 -0000 Received: (qmail 20760 invoked by uid 22791); 8 Sep 2009 13:02:28 -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; Tue, 08 Sep 2009 13:02:14 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id ABB6526EF08; Tue, 8 Sep 2009 15:02:09 +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 7A9B026EF06; Tue, 8 Sep 2009 15:02:09 +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> <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> In-Reply-To: <4AA64929.1040305@undo-software.com> Subject: RE: Simics & reverse execution Date: Tue, 08 Sep 2009 13:02:00 -0000 Message-ID: <01c001ca3084$908f30c0$b1ad9240$@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/msg00133.txt.bz2 > > 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. 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. > >> 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. 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. /jakob