From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15632 invoked by alias); 18 Apr 2006 18:56:22 -0000 Received: (qmail 15622 invoked by uid 22791); 18 Apr 2006 18:56:21 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 18 Apr 2006 18:56:19 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k3IIuH7T028645; Tue, 18 Apr 2006 14:56:18 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.11.6) with ESMTP id k3IIuHd0032083; Tue, 18 Apr 2006 14:56:17 -0400 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k3IIuGTq025122; Tue, 18 Apr 2006 14:56:16 -0400 Message-ID: <4445364F.506@redhat.com> Date: Tue, 18 Apr 2006 18:56:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sources.redhat.com Subject: Re: [RFA] Reverse debugging, part 3/3: user interface / docs References: <442DAAD9.6080509@redhat.com> <44442877.1060401@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00243.txt.bz2 Eli Zaretskii wrote: >>Date: Mon, 17 Apr 2006 16:44:55 -0700 >>From: Michael Snyder >>CC: gdb-patches@sources.redhat.com >> >>Please see revised patch, attached. >>OK now? > > > The corrections you made are okay, but you left two of my suggestions > unhandled, please at least explain why. > > >>>>+ Behavior of >>>>+ asynchronous signals depends on the target environment. >>> >>> >>>This is too vague. Can we at least mention the possible behaviors, or >>>just the most common/expected ones? The reader should get some idea >>>of what might happen. > > You didn't change anything in response to this comment. Well, I don't really have any idea what might happen -- and it's really out of GDB's hands. The target might do (almost literally) anything. It might ignore asynchronous signals completely. It might record and reproduce them faithfully. It might stick them in randomly. From the research that I've done into other reverse-execution implementations, this is an area that's not well understood by anybody. >>>>+ Run the program backward until control reaches the start of a >>>>+ different source line >>> >>> >>>Isn't it better to say >>> >>> Run the program backwards until control reaches the first instruction >>> of a different source line >>> >>>? In any case, "backwards", not "backward". > > > You left "backward" in the text. Um, yeah... Eli, the text already contains "backward" twice, and "backwards" only once, including *both* phrases "search backward" and "search backwards". I'm not convinced one is more correct than the other, nor that a consistant usage is demonstrated in context. That said, I guess I don't care all that strongly -- but "backward" sounds more correct to me here. If you like, I'll change it to "Run the program in reverse"... ;-)