From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19188 invoked by alias); 16 Sep 2005 17:50:06 -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 19113 invoked by uid 22791); 16 Sep 2005 17:49:59 -0000 Received: from yosemite.airs.com (HELO yosemite.airs.com) (205.217.158.180) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Fri, 16 Sep 2005 17:49:59 +0000 Received: (qmail 15031 invoked by uid 10); 16 Sep 2005 17:49:58 -0000 Received: (qmail 6577 invoked by uid 500); 16 Sep 2005 17:49:51 -0000 To: Stan Shebs Cc: gdb@sourceware.org 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> From: Ian Lance Taylor Date: Fri, 16 Sep 2005 17:50:00 -0000 In-Reply-To: <432ACFFB.9040204@apple.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2005-09/txt/msg00119.txt.bz2 Stan Shebs writes: > So I'm not questioning the value of the feature, but trying to get a > sense of the user requirements. Well, here are some comments based on how I use gdb. First, debugging a program with which I am not familiar, in order to locate a bug. Let's assume this is a reproducible bug. The first job is to find out where the bug is occurring. Reverse execution can help here with one of the examples that Stan gave. When I 'next' over a function, the bug might occur there. It would be convenient to be able to reverse over the function, and then step into it. In order to make that work most conveniently, it would be ideal if network and file input were replayed when going forward again. Basically, any invocation of the read system call would ideally return the same results as before. Similarly for the open, socket, and accept system calls and for system calls like ioctl (FIONREAD). For super extra credit, SIGIO and SIGURG signals would be repeated at the same time as before. For my purposes it's not necessary to replay network and file output. In fact, in some cases that would actually be less helpful. It would be better to just skip the output system calls. To put it another way, it's not necessary for my purposes to undo any system actions when stepping backward; it's merely helpful to replay the input calls when stepping forward again. Mind you, reverse execution would be useful even without the ability to replay system calls. It's just that it would be more useful if they could be replayed. Second, once the bug has been located, how did it happen? When this is not obvious, it's generally an issue of memory corruption or mysterious data structure manipulation. For this the most useful feature would be a reverse watchpoint, to walk backward to the point where the data was changed. Here again it is not necessary to undo system calls. I should note that this would only be useful if the reverse watchpoint were quite efficient; I don't know how feasible that is. I recall that non-hardware watchpoints were unusable. Third, a different scenario, the bug which can not be recreated at will. gdb isn't normally too helpful on these cases, but let's say for the sake of argument that we have a core dump or we can attach to a running process which shows the bug. Here again reverse execution could be helpful to pin down where the bug happened. However, it's hard for me to imagine this actually getting implemented, so I won't discuss it in detail. Hope this helps. Ian