From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16497 invoked by alias); 15 May 2013 18:20:51 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 16488 invoked by uid 89); 15 May 2013 18:20:51 -0000 X-Spam-SWARE-Status: No, score=-8.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 15 May 2013 18:20:50 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4FIKmJN001280 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 May 2013 14:20:48 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r4FIKkQD002590; Wed, 15 May 2013 14:20:47 -0400 Message-ID: <5193D1FE.9070804@redhat.com> Date: Wed, 15 May 2013 18:20:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sourceware.org Subject: Re: [PATCH 3/5] range stepping: gdb References: <20130514191026.13213.39574.stgit@brno.lan> <20130514191047.13213.8476.stgit@brno.lan> <83k3n173ao.fsf@gnu.org> <5193621C.50603@redhat.com> <83ppws5w00.fsf@gnu.org> <519381E9.3020007@redhat.com> <83bo8c5pb7.fsf@gnu.org> <5193948A.9090609@redhat.com> In-Reply-To: <5193948A.9090609@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00555.txt.bz2 On 05/15/2013 02:58 PM, Pedro Alves wrote: > On 05/15/2013 02:46 PM, Eli Zaretskii wrote: >>> Date: Wed, 15 May 2013 13:39:05 +0100 >>> From: Pedro Alves >>> CC: gdb-patches@sourceware.org >>> >>>> Doesn't this mean that these two use cases are explicit exceptions >>>> from the rule that END is excluded? >>> >>> Nope. There's no exception. >>> >>> With: >>> >>> vCont ;r START,END >>> >>> #1 - The stub single-steps the thread. >>> #2 - Once the thread stops, the stub checks whether the thread >>> stopped in the [START,END) range. If so, goto #1. >>> It not, goto #3. >>> #3 - The stub reports to gdb that the thread stopped stepping. >>> >>> If it happens that START and END are the same, then #2 always >>> goes to #3. >> >> I'm simulating a naive reader, while you are replying to someone you >> consider an experienced code developer ;-) So we are talking past >> each other. > > :-) > >> When you say "END is the address of the first instruction beyond the >> step range", that means, simply put, that execution will always stop >> before it executes the instruction at END. IOW, the instruction at >> END will _not_ be executed. With that interpretation, a range >> [START,START) is _empty_ and will never execute any instructions at >> all. >> >> It is OK to use a different interpretation, but then we should either >> (a) describe the semantics differently to begin with, or (b) explain >> that [START,START) is an exception. You seem to object to (b), which >> then brings us back at (a), meaning that this text: >> >>> +@var{end} is the address of the first instruction beyond the step >>> +range, and @strong{not} the address of the last instruction within it. >> >> needs to be reworded, so as not to say that END is _beyond_ the range. > > I see what you mean now. > >> If you want a specific response for the algorithm you show above, then >> I would ask why does GDB single-step the stub at all, when START and >> END are equal? The fact that we implemented this is a 'do-until' loop >> rather than a 'while' loop, i.e. test at the end instead of at the >> beginning, is an important implementation detail which must be present >> explicitly in the description of what this feature does. > > I agree. This is the sort of detail I could see different stubs > ending up implementing differently, so I wanted to be sure it > was clearly specified. Well, clearly I failed. :-) > >> The very need you felt to explain this is already a clear sign that >> the original description is wrong. > > I'll try to come up with a better description. What do you think of this? I'm okay with removing the whole second paragraph ("If the range is empty...") if you think the first paragraph is already clear enough. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @item r @var{start},@var{end} Step once, and then keep stepping as long as the thread stops at addresses between @var{start} (inclusive) and @var{end} (exclusive). The remote stub reports a stop reply when either the thread goes out of the range or is stopped due to an unrelated reason, such as hitting a breakpoint. @xref{range stepping}. If the range is empty (@var{start} == @var{end}), then the action becomes equivalent to the @samp{s} action. In other words, single-step once, and report the stop (even if the stepped instruction jumps to @var{start}). (A stop reply may be sent at any point even if the PC is still within the stepping range; for example, it is valid to implement this packet in a degenerate way as a single instruction step operation.) @end table ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -- Pedro Alves