From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18717 invoked by alias); 25 Apr 2014 10:23:02 -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 18602 invoked by uid 89); 25 Apr 2014 10:23:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 25 Apr 2014 10:23:00 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3PAMvV1001989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Apr 2014 06:22:58 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s3PAMu33020646; Fri, 25 Apr 2014 06:22:57 -0400 Message-ID: <535A3780.4010302@redhat.com> Date: Fri, 25 Apr 2014 10:23:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Partially available/unavailable data in requested range References: <1397998086-750-1-git-send-email-yao@codesourcery.com> <53593996.2020806@redhat.com> <535A2169.7020905@codesourcery.com> In-Reply-To: <535A2169.7020905@codesourcery.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg00528.txt.bz2 On 04/25/2014 09:48 AM, Yao Qi wrote: > I thought of this when I wrote this patch. I was unable to figure > out your trim-LEN-up trick, and get the code complicated. Given > "requesting memory across sections" is a rare case, I didn't go on > this track further. Well... On 04/25/2014 09:48 AM, Yao Qi wrote: > On 04/25/2014 12:19 AM, Pedro Alves wrote: >> first_addr_available is clearer than min_addr_available"). > > I don't think "first" is clearer than "min". There are multiple 'M' > blocks in a traceframe, and the address of some of them are within the > desired range [OFFSET, OFFSET + LEN). We are looking for the minimal > address within the range, instead of the first address within the range. > For example, supposing we have three 'M' blocks, M1 (0x01 0x02), > M2 (0x07, 0x08) and M3 (0x4, 0x05), and the requested range is > [0x03, 0x09), the first 'M' block within this range is M2, while the > minimal address of 'M' block is M3. M3 is what we are looking for. It confused me, because I read "minimal" as in "only barely adequate". And then we have "maddr", starting with "m", and "M" blocks. That's a lot of unrelated 'm's. I can see now how "first" might be confusing as well, as leading to think that it's the first we encounter. Maybe "low" would be even better: /* Records the lowest available address of all blocks that intersects the requested range. */ ULONGEST low_addr_available = 0; > In my patch, there is one more condition check > > if (offset < maddr && maddr < (offset + len)) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > if (min_addr_available == 0 || min_addr_available > maddr) > min_addr_available = maddr; > > to avoid recoding minimal address *outside* of requested range. For > example, we have three 'M' blocks, M1 (0x01 0x02), M2 (0x07, 0x08) and > M3 (0x04, 0x05), and the requested range is [0x03, 0x09). > > OFFSET > |--- requested ---| > |-M1-| |-M2-| |-M3-| > > The MIN_ADDR_AVAILABLE is expected to be 0x04 instead of 0x01. Ah, indeed. Thanks, -- Pedro Alves