From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2520 invoked by alias); 13 Sep 2005 03:43:04 -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 2425 invoked by uid 22791); 13 Sep 2005 03:42:28 -0000 Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 13 Sep 2005 03:42:28 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-90-43.inter.net.il [80.230.90.43]) by romy.inter.net.il (MOS 3.5.8-GR) with ESMTP id CJG30572 (AUTH halo1); Tue, 13 Sep 2005 06:42:20 +0300 (IDT) Date: Tue, 13 Sep 2005 03:43:00 -0000 Message-Id: From: Eli Zaretskii To: Stan Shebs CC: gdb@sources.redhat.com In-reply-to: <432628AA.2040808@apple.com> (message from Stan Shebs on Mon, 12 Sep 2005 18:17:30 -0700) Subject: Re: Using reverse execution Reply-to: Eli Zaretskii References: <432628AA.2040808@apple.com> X-SW-Source: 2005-09/txt/msg00082.txt.bz2 > Date: Mon, 12 Sep 2005 18:17:30 -0700 > From: Stan Shebs > > But will users actually use any of this in real life? "Undo" is pretty > easy - everybody understands "undo", even nonprogrammers, with many > GUIs giving it a dedicated keystroke. Tracking data backwards through > a program is a powerful tool for a tough class of bugs, but as we know > from past experience, powerful features that are at all hard to use > are often ignored. Single-instruction reverse stepping is conceptually > simpler, but likely to see more interest from the low-level > developers, and may only be interesting if available for kernel > debugging and the like. Reproducibility problems crop up regularly, so > I can see people wanting to use reverse execution after a breakpoint > sets them down in rarely-executed code. > > Once we have an idea of what we think users will want from the > feature, we'll have a better idea of what characteristics and > limitations might be acceptable in an implementation. You said it yourself several times: 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". The various "undo" facilities are different: they let you correct a mistakenly taken action. That's not what backwards debugging is about. 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.