From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23962 invoked by alias); 23 Sep 2005 23:20:40 -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 23939 invoked by uid 22791); 23 Sep 2005 23:20:28 -0000 Received: from mail-out3.apple.com (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 23 Sep 2005 23:20:28 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id j8NNKL1d015881; Fri, 23 Sep 2005 16:20:21 -0700 (PDT) Received: from [17.219.207.38] (unknown [17.219.207.38]) by relay6.apple.com (Apple SCV relay) with ESMTP id 5FB654AF; Fri, 23 Sep 2005 16:20:20 -0700 (PDT) Message-ID: <43348DB4.5000206@apple.com> Date: Fri, 23 Sep 2005 23:20:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.12) Gecko/20050915 MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Using reverse execution References: <432628AA.2040808@apple.com> <43277083.1040708@apple.com> <4328A574.5080906@apple.com> <43290862.9040204@apple.com> <4329D5A3.8030202@apple.com> <432ACFFB.9040204@apple.com> <432B08CA.8070902@apple.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00174.txt.bz2 (Been in Cupertino talking about reverse execution to Apple people, just now getting caught up) Eli Zaretskii wrote: >>Date: Fri, 16 Sep 2005 11:02:50 -0700 >>From: Stan Shebs >>Cc: gdb@sources.redhat.com >> >>Eli Zaretskii wrote: >> >> >>>What features can be implemented without hacking the kernel? >>> >>> >>If you limited reversing to designated regions, and single-stepped >>every instruction in the range, collected the exact data changes >>(by disassembling the instructions) and only allowed examination >>rather than re-executing from any given point, all that just needs >>existing GDB machinery. Is it useful? >> > >Sorry, you lost me. Can you describe this in smaller words? > ODB works by hacking up the bytecode interpreter to log what every bytecode does, recording addresses and data values. After the program runs, you have a gigantic log, and you look at it with a debugger-type interface. Since the log contains every before-and-after change to objects etc, it's just a matter of rooting through it to be able to display any value at any time. But the program execution is already over, so there's no way to set a variable and continue, call a method, or do anything else to alter execution. An analogy I used this week is that of a "time-traveler's telescope" - you can focus in on any point in the past, and study it closely from the present day, but you can't alter it. A handy way to sidestep paradox, but it also precludes "what-if" experiments; you'd have to restart the program before you could make the program go a different way. >>At least somebody thinks so, because I just described how the >>omniscient debugger works (using Java bytecodes instead of machine >>instructions). >> > >As I understood the description of the omniscient debugger, it would >be very useful. > Indeed it seems so. That would be a very nice outcome - we could get a powerful new feature without having to make a scarily-large commitment to a feature that doesn't current have a large body of users demanding it already. Stan