From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20960 invoked by alias); 8 Sep 2009 07:21:30 -0000 Received: (qmail 20894 invoked by uid 22791); 8 Sep 2009 07:21: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 vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Sep 2009 07:21:20 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 7A3E326EF24; Tue, 8 Sep 2009 09:21:17 +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 4A33426EF08; Tue, 8 Sep 2009 09:21:17 +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> In-Reply-To: <4AA4F724.1050708@undo-software.com> Subject: RE: Simics & reverse execution Date: Tue, 08 Sep 2009 07:21:00 -0000 Message-ID: <017001ca3054$f2d26020$d8772060$@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/msg00129.txt.bz2 > > Think about the cross-product with thread handling. If you use time > > there, you need to determine how to handle times for threads. One > > timeline per thread? Or a global system time? > > Oh right, yes, I was assuming global. > > If time were per thread, then yes, I can see how that would quickly get > very complicated. And I think time is per-thread in process record, as that is based on instruction counts. Not to mention to synch time across multiple processors which are executing in parallel... that is a very non-trivial problem in practice. > > You also really like to have time breakpoints in the system, to > > allow you to do things like "run this system for 6.132 seconds and > > then stop" (typical operation we do when skipping a boot sequence or > > we have run a workload several times and know when itneresting > > things should start to happen). > > I would argue that's a future feature. Time-based breakpoints would > seem a very nice thing to have, but a system which had get/set time > commands but no time breakpoints would be a lot more more useful than > one with neither. True. And actually, if you "set" time to 6.132 seconds in my example, a smart backend would do the same... execute until that point even if it was not already executed. That's what Simics does, I think. > > Also, how should this interact with non-stop debug? And how should > > you handle multiple active processor cores running parallel threads? > > I must confess, I haven't given much thought at all to the interaction > of non-stop debug with reverse debugging in general. I haven't been > following too closely, but aren't they currently incompatible anyway? > (something to do with displaced breakpoints not working well with > reverse). But I don't see how it's any worse than the bookmarks case. > In fact, I don't see how any of it differs from use with bookmarks. All > we're really talking about is a different way to describe a point in > history. The problem is that different backends have different natural semantics here. A simulator has a natural semantic of synchronous stop across all processors, devices, and everything else going on. A hardware across JTAG is far more likely to stop just a few cores and keep the rest running. Hardware with recording: ???? 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. > 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. /jakob