From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24961 invoked by alias); 7 Sep 2009 08:24:40 -0000 Received: (qmail 24934 invoked by uid 22791); 7 Sep 2009 08:24:38 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from oden.vtab.com (HELO oden.vtab.com) (62.20.90.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 07 Sep 2009 08:24:29 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id C608C26EF19; Mon, 7 Sep 2009 10:24:25 +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 9963526EEE3; Mon, 7 Sep 2009 10:24:25 +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> In-Reply-To: <4AA4C0A4.7000509@undo-software.com> Subject: RE: Simics & reverse execution Date: Mon, 07 Sep 2009 08:24:00 -0000 Message-ID: <009b01ca2f94$9d6508b0$d82f1a10$@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/msg00113.txt.bz2 > > 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. 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? 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). Also, how should this interact with non-stop debug? And how should you handle multiple active processor cores running parallel threads? > > 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). Me neither... /jakob