From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 58766 invoked by alias); 13 Apr 2017 08:18:38 -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 58741 invoked by uid 89); 13 Apr 2017 08:18:37 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wr0-f169.google.com Received: from mail-wr0-f169.google.com (HELO mail-wr0-f169.google.com) (209.85.128.169) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Apr 2017 08:18:36 +0000 Received: by mail-wr0-f169.google.com with SMTP id l28so30890137wre.0 for ; Thu, 13 Apr 2017 01:18:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=AEOOvidS8EfeUJZGF6gQkthmsYXQp//NYLEJQ63cGQc=; b=dalNm37sf+yI5Xq5U57OBOFVgvxFXE0EP9Pp/zFdqQxatHiqmw5HqBytGr86y8Z6NG IpMR5tQZCAxhNff4yeu4KscZzWr8BRZ/BggD7/QL+Ncx2E2AErRYSGEEfKVdqIv7L6mH 6xuF4QWeky27cS3r334IDNoDs4MFDsvN51RiTaSHYCn7WhrsxG4xcjDKtWXFFBo8lXCt xuQ3ZXGXF6srspUM/+XURq91RHxnI16PKOMsj5ddFY/hzQXl89X6euUMBk0uOsHCOzdZ 7x4B7SEOp8Io1CIDNEj+HeQn5ii7QuCXZDEqQ3HmnsZYiI+njnN3f+H8SYq/mMhKoP/Z VnuA== X-Gm-Message-State: AN3rC/4kNiHupC+LEZjIdIL1fpend6+qzkHhgZgII3YgejdF/HH+/b60 2LXRgv5t8PYodg== X-Received: by 10.223.155.210 with SMTP id e18mr1549813wrc.165.1492071516233; Thu, 13 Apr 2017 01:18:36 -0700 (PDT) Received: from E107787-LIN ([194.214.185.158]) by smtp.gmail.com with ESMTPSA id c16sm510112wrb.56.2017.04.13.01.18.35 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Thu, 13 Apr 2017 01:18:35 -0700 (PDT) From: Yao Qi To: Andreas Arnez Cc: gdb-patches@sourceware.org Subject: Re: [PATCH 2/9] Fix size capping in write_pieced_value References: <1491586736-21296-1-git-send-email-arnez@linux.vnet.ibm.com> <1491586736-21296-3-git-send-email-arnez@linux.vnet.ibm.com> Date: Thu, 13 Apr 2017 08:18:00 -0000 In-Reply-To: <1491586736-21296-3-git-send-email-arnez@linux.vnet.ibm.com> (Andreas Arnez's message of "Fri, 7 Apr 2017 19:38:09 +0200") Message-ID: <86r30wafft.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00404.txt.bz2 Andreas Arnez writes: > A field in a structure composed of DWARF pieces overlaps one or more of > those pieces. When writing to the field, the beginning of the first and > the end of the last of those pieces may have to be skipped. But the Do you have an example? > logic in write_pieced_value for handling this is flawed when there are > actually bits to skip at the beginning of the first piece: it truncates > the piece size towards the end *before* accounting for the skipped bits > at the beginning instead of the other way around. > > Note that the same bug was already found in read_pieced_value and fixed > there (but not in write_pieced_value), see PR 15391. Can we share the code in write_pieced_value and read_pieced_value? The code computing offsets and bits should be shared. Also, we need more comments in the code to explain these offsets and bits, a diagram about the relationships of these bits and offsets is quite helpful. --=20 Yao (=E9=BD=90=E5=B0=A7)