From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15023 invoked by alias); 9 Dec 2013 21:04: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 15008 invoked by uid 89); 9 Dec 2013 21:04:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: mail-gw1-out.broadcom.com Received: from Unknown (HELO mail-gw1-out.broadcom.com) (216.31.210.62) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Dec 2013 21:04:50 +0000 Received: from irvexchcas06.broadcom.com (HELO IRVEXCHCAS06.corp.ad.broadcom.com) ([10.9.208.53]) by mail-gw1-out.broadcom.com with ESMTP; 09 Dec 2013 13:09:13 -0800 Received: from IRVEXCHSMTP2.corp.ad.broadcom.com (10.9.207.52) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Mon, 9 Dec 2013 13:04:42 -0800 Received: from mail-irva-13.broadcom.com (10.10.10.20) by IRVEXCHSMTP2.corp.ad.broadcom.com (10.9.207.52) with Microsoft SMTP Server id 14.1.438.0; Mon, 9 Dec 2013 13:04:41 -0800 Received: from [10.177.252.205] (unknown [10.177.252.205]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 06BDE246A5; Mon, 9 Dec 2013 13:04:40 -0800 (PST) Message-ID: <52A63067.8050702@broadcom.com> Date: Mon, 09 Dec 2013 21:04:00 -0000 From: Andrew Burgess User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: Pedro Alves CC: Subject: Re: [PATCH [2/2] Convert the unavailable vector to be bit, not byte, based. References: <529F489F.7070805@broadcom.com> <529F498F.7060909@broadcom.com> <52A0A760.8000509@redhat.com> In-Reply-To: <52A0A760.8000509@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00351.txt.bz2 On 05/12/2013 4:18 PM, Pedro Alves wrote: > On 12/04/2013 03:26 PM, Andrew Burgess wrote: > >> >> /* Compare the _available_ contents. */ >> - if (memcmp (val1->contents + offset1, >> - val2->contents + offset2, >> - l1) != 0) >> + if (memcmp (val1->contents + (offset1 / TARGET_CHAR_BIT), >> + val2->contents + (offset2 / TARGET_CHAR_BIT), >> + (l1 / TARGET_CHAR_BIT)) != 0) >> return 0; > > As memcmp compares bytes, isn't this potentially comparing bits > at the beginning and end of the values' buffers, when it > should not? That is, it looks like the > 'offset1 % TARGET_CHAR_BIT != 0' and > '(offset1 + l1) % TARGET_CHAR_BIT' cases should be considered here? > Thanks for the review. You're right, this isn't doing the correct thing here, I should have written something like this: + if (memcmp (val1->contents + (offset1 / TARGET_CHAR_BIT), + val2->contents + (offset2 / TARGET_CHAR_BIT), + ((l1 + TARGET_CHAR_BIT - 1)/ TARGET_CHAR_BIT)) != 0) That is round the start down to the nearest byte boundary, and round the length up to the nearest byte boundary. I figured that as the value content buffer is always a round number of bytes then there will always be memory backing the access, and as the content buffer is zero initialized comparing the "unavailable" bits will not cause the compare to fail. Alternatively, I can update to only access the bits we'd like to compare. Which approach would would be best? Thanks for your advice, Andrew