From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6476 invoked by alias); 13 Apr 2017 16:35:12 -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 6451 invoked by uid 89); 13 Apr 2017 16:35:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_ASCII_DIVIDERS,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy= X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 13 Apr 2017 16:35:11 +0000 Received: from pps.filterd (m0098393.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3DGSZiB074052 for ; Thu, 13 Apr 2017 12:35:11 -0400 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0a-001b2d01.pphosted.com with ESMTP id 29t7kp8g62-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Apr 2017 12:35:10 -0400 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 13 Apr 2017 17:35:08 +0100 Received: from b06cxnps3074.portsmouth.uk.ibm.com (9.149.109.194) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 13 Apr 2017 17:35:07 +0100 Received: from d06av24.portsmouth.uk.ibm.com (mk.ibm.com [9.149.105.60]) by b06cxnps3074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v3DGZ7sH15728926; Thu, 13 Apr 2017 16:35:07 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E5F964204C; Thu, 13 Apr 2017 17:34:11 +0100 (BST) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id BECC842041; Thu, 13 Apr 2017 17:34:11 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.162]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Thu, 13 Apr 2017 17:34:11 +0100 (BST) From: Andreas Arnez To: Yao Qi 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> <86r30wafft.fsf@gmail.com> Date: Thu, 13 Apr 2017 16:35:00 -0000 In-Reply-To: <86r30wafft.fsf@gmail.com> (Yao Qi's message of "Thu, 13 Apr 2017 09:18:30 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 x-cbid: 17041316-0008-0000-0000-00000425FCA2 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041316-0009-0000-0000-00001D414C9A Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-13_11:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704130139 X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00444.txt.bz2 On Thu, Apr 13 2017, Yao Qi wrote: > 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? OK, I guess the commit message should be improved a bit. How about this? A field f in a structure composed of DWARF pieces may be located in multiple pieces, where the first and last of those may contain bits from other fields as well. So when writing to f, the beginning of the first and the end of the last of those pieces may have to be skipped. But the logic in write_pieced_value for handling one of those pieces is flawed when the first and last piece are the same, i.e., f is contained in a single piece: < - - - - - - - - - piece_size - - - - - - - - - -> +-------------------------------------------------+ | skipped_bits | f_bits | / / / / / / / / / / | +-------------------------------------------------+ The current logic determines the size of the sub-piece to operate on by limiting the piece size to the bit size of f and then subtracting the skipped bits: max (piece_size, f_bits) - skipped_bits Instead of: max (piece_size - skipped_bits, f_bits) So the resulting sub-piece size is corrupted, leading to wrong handling of this piece in write_pieced_value. > >> 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. Yes. I have another patch (not posted yet) that merges these two functions. I moved that towards the end of the patch series, so the individual fixes can be incremental. > 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. OK. Some of the offset variables are removed by my patches, so I guess I'll postpone that to the merged version. I'll see what I can come up with and include it in v2. -- Andreas