From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10751 invoked by alias); 14 Sep 2005 00:36:36 -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 10693 invoked by uid 22791); 14 Sep 2005 00:36:27 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 14 Sep 2005 00:36:26 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j8E0aJJi027573; Tue, 13 Sep 2005 17:36:19 -0700 (PDT) Received: from [17.219.206.115] (unknown [17.219.206.115]) by relay6.apple.com (Apple SCV relay) with ESMTP id 73B284A6; Tue, 13 Sep 2005 17:36:19 -0700 (PDT) Message-ID: <43277083.1040708@apple.com> Date: Wed, 14 Sep 2005 00:36:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910 MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: Using reverse execution References: <432628AA.2040808@apple.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00091.txt.bz2 Eli Zaretskii wrote: > [...] looking for a bug is fundamentally > >a go-backward problem. When you debug a program, you start from some >manifestation of a bug, and mentally go backwards trying to find out >"whodunit". > > I think it's a strong and unproven claim to say that the backwards reasoning of the mental deduction process implies that users will find reverse execution a natural mode of debugging. For example, imperative programming is strongly time-oriented - "do this, then that, then the other thing". Stepping backwards from the else clause of an if, or from a label to the goto can be kind of jarring. Stepping backwards through an undoable operation is going to require one to remember that the packet is not actually un-sent; multiple backward steps (say through remote.c) could turn into a new and unpleasant sort of memory game. It may indeed be true that users will instantly take to reverse execution - I believe the Simics folks have made that claim - but I don't think we yet have enough data to justify the general conclusion. >The various "undo" facilities are different: they let you correct a >mistakenly taken action. That's not what backwards debugging is >about. > > What I'm getting at is that maybe that's the only thing users would want to use reverse execution for. It would be ironic if we worked up elaborate machinery, and we find users only caring about getting back to the last checkpoint so they can try single-stepping forward again. >The challenge is to implement going backwards in a way that won't >overcomplicate its usage. But I think we can manage that, if we rely >on checkpoints and implement going backwards by unrolling to the >previous checkpoint and then stepping forward. > > That's the general implementation theory, complicated by shared memory, thread switching, multiple CPUs, and other nasty things. :-) Stan