From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6839 invoked by alias); 29 Aug 2009 07:24:41 -0000 Received: (qmail 6825 invoked by uid 22791); 29 Aug 2009 07:24:39 -0000 X-SWARE-Spam-Status: No, hits=-1.9 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; Sat, 29 Aug 2009 07:24:32 +0000 Received: from oden.vtab.com (oden.vtab.com [127.0.0.1]) by oden.vtab.com (Postfix) with ESMTP id DCC9026EF24; Sat, 29 Aug 2009 09:24:28 +0200 (CEST) Received: from polhem (c83-253-21-30.bredband.comhem.se [83.253.21.30]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by oden.vtab.com (Postfix) with ESMTP id B716426EF09; Sat, 29 Aug 2009 09:24:28 +0200 (CEST) From: "Jakob Engblom" To: "'Greg Law'" , "'Eli Zaretskii'" Cc: References: <00cf01ca265a$d4110dc0$7c332940$@com> <83tyzucw8p.fsf@gnu.org> <002b01ca27c7$1316d8c0$39448a40$@com> <833a7ccj52.fsf@gnu.org> <4A97BA98.4010105@undo-software.com> <83y6p4aweu.fsf@gnu.org> <4A980D06.40002@undo-software.com> In-Reply-To: <4A980D06.40002@undo-software.com> Subject: RE: GDB MI Reverse Commands added [2 of 3] Date: Sat, 29 Aug 2009 07:37:00 -0000 Message-ID: <00c701ca2879$bf7992d0$3e6cb870$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-08/txt/msg00533.txt.bz2 > Yes, that's ok. But I'm struggling to think of a plausible way in which > a target could provide reverse debugging without some kind of log. Any > stateful program will clobber its state as it runs, and so to go > backwards you need to have a log somewhere that tells you what the state > was before you clobbered it. And it will not be possible to go > backwards to a time before you started recording. Easy. Deterministic replay. In the case we are reversing a Simics session that has no asynch IO from the outside world, there is no log being used. We are just replaying the same execution scenario from the start. Typical example: initial boot of a system. First, U-Boot comes up, receives scripted input, and fires off a Linux kernel, which also will not communicate with anything uncontrolled until the serial terminal is up at the end of the boot. Until that time, everything is under simulator control and can be replayed without using a log -- all parts of the system, including the network and the simulated DHCP server, are deterministic in the strongest sense. So, no, a "log" is not necessarily the implementation of reversible debug. Normally, a log IS involved if you have asynch interaction with the outside world, but there are many useful simulations that do not do that. A second question here: to me, "inferior" means whatever is being debugged. Is that a correct interpretation? So "inferior" can be a piece of firmware, an operating system, or any other sequence of code to which gdb is attached? I think that some people tend to think of it as user-level programs, which is the common case on desktops, but in the embedded world where I live, most often the inferior is an entire system... and the user programs might be discovered only in the debugger UI that faces the user, while gdb is used to communicate with the taraet machine. So I think of "inferior" as not just user programs. Is that OK? /jakob