From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16600 invoked by alias); 15 May 2013 13:58:39 -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 16590 invoked by uid 89); 15 May 2013 13:58:38 -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 13:58:38 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r4FDwaKQ008675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 May 2013 09:58:36 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r4FDwYww018670; Wed, 15 May 2013 09:58:35 -0400 Message-ID: <5193948A.9090609@redhat.com> Date: Wed, 15 May 2013 13:58: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> In-Reply-To: <83bo8c5pb7.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-05/txt/msg00528.txt.bz2 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. Thanks! -- Pedro Alves