From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28935 invoked by alias); 24 May 2005 04:47:08 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28909 invoked by uid 22791); 24 May 2005 04:47:02 -0000 Received: from rwcrmhc11.comcast.net (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 24 May 2005 04:47:02 +0000 Received: from [10.0.1.2] (c-24-61-199-96.hsd1.nh.comcast.net[24.61.199.96]) by comcast.net (rwcrmhc11) with SMTP id <2005052404470001300ft2g5e>; Tue, 24 May 2005 04:47:00 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 24 May 2005 04:47:00 -0000 Subject: Re: [discuss] going back: reverse-execution vs. checkpoint/restart From: Paul Schlie To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2005-05/txt/msg00295.txt.bz2 In hopes it may be helpful, upon reviewing some of the earlier posts: - checkpoints/undo-reverse can never "fail" even if the current program state is manually modifed, as by definition a check-pointed state represents the "state" of the program at some previous point in time, therefore insensitive to it's current state (altered or not, with a caveat noted below). - it's likely a good idea to differentiate check-pointing a process or even a thread running on an OS, from check-pointing the entire machine inclusive of the OS and all of it's processes. (as where the later may be infeasible in the general case except for very small embedded systems, the former may be typically reasonable with the understanding that the state of the world around it on the other side of the system interfaces represented in other process states would not have been check-pointed, therefore are in what ever state they were last in; which is likely of little consequence if one is attempting to debug an algorithm which doesn't make sensitive system calls, however if a socket was opened in a network protocol loop but not closed prior to reverting to a previous program state which may have been prior to the socket being originally opened, things could get weird, so there's no magic, powerful features may require delicate piloting.) - in all reasonably useful cases, GDB has direct access to all the information required without necessity of explicit target support, who's implementation my be partitioned in such a way that targets may then improve the efficiency of the solution in an incremental manor depending on the sophistication of the target, without requiring that any target support any particular feature to enable basic check-point/restart, and undo-reverse execution; although it will be true that in order to achieve a level of efficiency likely required to interactively do so for large complex processes, some amount of target assist may be practically necessary (however there's no magic, check-pointing an entire multi-process platform may never be practical under any circumstance, regardless of target support or not).