From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21727 invoked by alias); 28 Aug 2009 17:34:53 -0000 Received: (qmail 21716 invoked by uid 22791); 28 Aug 2009 17:34:52 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 28 Aug 2009 17:34:46 +0000 Received: from jupiter.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id CF39A20001; Fri, 28 Aug 2009 10:34:42 -0700 (PDT) Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) by jupiter.vmware.com (Postfix) with ESMTP id C4EA9DC09B; Fri, 28 Aug 2009 10:34:42 -0700 (PDT) Message-ID: <4A981551.4060504@vmware.com> Date: Fri, 28 Aug 2009 18:49:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Eli Zaretskii CC: Greg Law , "jakob@virtutech.com" , "gdb-patches@sourceware.org" Subject: Re: GDB MI Reverse Commands added [2 of 3] 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> <83ljl3c16f.fsf@gnu.org> In-Reply-To: <83ljl3c16f.fsf@gnu.org> Content-Type: text/plain; charset=iso-8859-1; format=flowed 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/msg00521.txt.bz2 Eli Zaretskii wrote: >> Date: Fri, 28 Aug 2009 17:59:50 +0100 >> From: Greg Law >> CC: jakob@virtutech.com, gdb-patches@sourceware.org >> >> But I'm struggling to think of a plausible way in which >> a target could provide reverse debugging without some kind of log. > > Don't we have already some kind of that implemented by forking the > inferior several times, and then switching to the appropriate fork > when the user wants to go backwards? You're thinking of checkpoint and restart. It does allow you to go back to a previous state, but it's functionally orthogonal to reverse. > Anyway, a target could conceivably provide reverse execution without > any need for GDB to do that for it. I don't think the manual should > be too tied to what we currently have, because then it would be a pain > to maintain. I see your point, but OTOH all of the current implementations rely on a log of some sort, and I agree with Greg that it isn't easy to imagine one that didn't. I think we should mention that "running off the end of the log" is one way in which a reverse continue may terminate, because in fact that is something that may happen in all of the current implementations.