From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9908 invoked by alias); 14 Sep 2005 03:42: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 9881 invoked by uid 22791); 14 Sep 2005 03:42:03 -0000 Received: from nitzan.inter.net.il (HELO nitzan.inter.net.il) (192.114.186.20) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 14 Sep 2005 03:42:03 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-203-116.inter.net.il [80.230.203.116]) by nitzan.inter.net.il (MOS 3.6.5-GR) with ESMTP id BKM25052 (AUTH halo1); Wed, 14 Sep 2005 06:41:59 +0300 (IDT) Date: Wed, 14 Sep 2005 03:42:00 -0000 Message-Id: From: Eli Zaretskii To: Stan Shebs CC: gdb@sources.redhat.com In-reply-to: <43277083.1040708@apple.com> (message from Stan Shebs on Tue, 13 Sep 2005 17:36:19 -0700) Subject: Re: Using reverse execution Reply-to: Eli Zaretskii References: <432628AA.2040808@apple.com> <43277083.1040708@apple.com> X-SW-Source: 2005-09/txt/msg00093.txt.bz2 > Date: Tue, 13 Sep 2005 17:36:19 -0700 > From: Stan Shebs > Cc: gdb@sources.redhat.com > > 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. I find this natural to the degree that it doesn't need any proof. > Stepping backwards from the else clause > of an if, or from a label to the goto can be kind of jarring. That's not what you do when you trace a bug. You start from the place where, e.g., the program gets a SIGSEGV, and then unroll it back to possible places where the corruption could have happened. That is, you try to guess where the problem could have originated from, and then get there and look around for clues. I don't find this jarring in any way. > >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. :-) Life is full of complications. That doesn't mean we should do nothing, just that we should understand the limitations.