From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27104 invoked by alias); 26 Oct 2009 07:58:19 -0000 Received: (qmail 27095 invoked by uid 22791); 26 Oct 2009 07:58:18 -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; Mon, 26 Oct 2009 07:58:13 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id 46AFF26EEFD; Mon, 26 Oct 2009 08:58:11 +0100 (CET) Received: from polhem (c83-253-31-27.bredband.comhem.se [83.253.31.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id 19A8626EF2D; Mon, 26 Oct 2009 08:58:11 +0100 (CET) From: "Jakob Engblom" To: "'Michael Snyder'" , "'Marc Khouzam'" Cc: References: <4ADA4BD8.6080800@vmware.com> <4ADCAA6B.5000606@vmware.com> In-Reply-To: <4ADCAA6B.5000606@vmware.com> Subject: RE: [FYI] tutorial for process record and reverse debugging Date: Mon, 26 Oct 2009 08:02:00 -0000 Message-ID: <009f01ca5612$10df2520$329d6f60$@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-10/txt/msg00372.txt.bz2 > > Seems to me that if you're replaying, and you reach the end of the > recorded log, at least one natural thing to do is to stop. Could be > that another natural thing to do would be to automatically switch > from replay mode to record mode and keep going -- but I'm not sure > if I could safely assume that that was the user's desire. > > Sounds like a case for a query, and/or a user-settable mode. Unless the backend tool is one that silently goes on recording here, like I know Simics does and I presume any other simulation-based solution will. And VMWare-style virtual-machine-based solutions. So a query for how a target behaves would be nice. In our experience, going on recording seems to be the natural thing to do. You can look at this way: the end of recording is nothing a user knows about, as the extent of the recording in time is a tool implementation aspect. As far as the user is concerned, the program is being reversed and run forward, without much care for how far into the execution they have gotten at any particular point in user time. If you want to execute for a bounded amount, use a "continue N cycles"-style command (which gdb does not have either). /jakob