From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29333 invoked by alias); 14 Sep 2005 22:34:37 -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 29311 invoked by uid 22791); 14 Sep 2005 22:34:32 -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 22:34:32 +0000 Received: from relay5.apple.com (a17-128-113-35.apple.com [17.128.113.35]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id j8EMYSTc020929; Wed, 14 Sep 2005 15:34:28 -0700 (PDT) Received: from [17.219.207.253] (unknown [17.219.207.253]) by relay5.apple.com (Apple SCV relay) with ESMTP id DC6AC324002; Wed, 14 Sep 2005 15:34:27 -0700 (PDT) Message-ID: <4328A574.5080906@apple.com> Date: Wed, 14 Sep 2005 22:34: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> <43277083.1040708@apple.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-09/txt/msg00099.txt.bz2 Eli Zaretskii wrote: >>Date: Tue, 13 Sep 2005 17:36:19 -0700 >>From: Stan Shebs >>Cc: gdb@sources.redhat.com >> > >>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. > > But have you actually done any debugging by reverse execution yourself? What you describe is the reason we hypothesize that reverse execution is a useful feature, not the evidence that our users will flock to it. As a comparison, for tracepoints we came up with various scenarios for how they would be amazingly useful and powerful, and yet after nearly a decade they remain a curiosity in GDB. One could argue that they're lacking native support, or need better documentation, or whatever, but if that's true, then the attractiveness of tracepoints depends as much on getting those details right as on the general concept. So that's the kind of question I'm asking for reverse execution - what do we think it takes to make it useful? Do we have to be be able to undo all system calls, or is it sufficient to just skip over them somehow? Should executing forward after reversal re-execute system calls, or skip over them, or should there be a sort of virtual/real option? Do we have to be able to unroll back to the beginning of the program, or can we usefully limit the range? Is there any more risk to users than they incur now when calling a function in the inferior? Reversing is likely to be slower - how much is acceptable? Will an incomplete mechanism still be interesting, or would it get a bad reputation such that no one will use it? Stan