From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40153 invoked by alias); 18 Apr 2017 17:25: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 40095 invoked by uid 89); 18 Apr 2017 17:25:01 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,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; Tue, 18 Apr 2017 17:25:00 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v3IHOphq039732 for ; Tue, 18 Apr 2017 13:25:00 -0400 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0a-001b2d01.pphosted.com with ESMTP id 29wmrp7cw5-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 18 Apr 2017 13:25:00 -0400 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 18 Apr 2017 18:24:57 +0100 Received: from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 18 Apr 2017 18:24:55 +0100 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v3IHOtY032243908; Tue, 18 Apr 2017 17:24:55 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B33E6A4057; Tue, 18 Apr 2017 18:23:56 +0100 (BST) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 83FEFA4040; Tue, 18 Apr 2017 18:23:56 +0100 (BST) Received: from oc1027705133.ibm.com (unknown [9.152.212.162]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Tue, 18 Apr 2017 18:23:56 +0100 (BST) From: Andreas Arnez To: Simon Marchi Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 4/9] Remove addr_size field from struct piece_closure References: <1491586736-21296-1-git-send-email-arnez@linux.vnet.ibm.com> <1491586736-21296-5-git-send-email-arnez@linux.vnet.ibm.com> <86inm8ad1y.fsf@gmail.com> <6fef62cbc51a5ff8f23b92612cf267ac@polymtl.ca> Date: Tue, 18 Apr 2017 17:25:00 -0000 In-Reply-To: <6fef62cbc51a5ff8f23b92612cf267ac@polymtl.ca> (Simon Marchi's message of "Thu, 13 Apr 2017 23:38:20 -0400") 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: 17041817-0008-0000-0000-000004297BE3 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041817-0009-0000-0000-00001D4DC24C Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-18_15:,, 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-1704180137 X-IsSubscribed: yes X-SW-Source: 2017-04/txt/msg00516.txt.bz2 On Thu, Apr 13 2017, Simon Marchi wrote: > On 2017-04-13 05:10, Yao Qi wrote: >> Andreas Arnez writes: >> >>> The addr_size field in the piece_closure data structure is a relic from >>> before introducing the typed DWARF stack. It is obsolete now. This >>> patch >>> removes it. >>> >>> gdb/ChangeLog: >>> >>> * dwarf2loc.c (struct piece_closure) : Remove field. >>> (allocate_piece_closure): Drop addr_size parameter. >>> (dwarf2_evaluate_loc_desc_full): Adjust call to >>> allocate_piece_closure. >> >> LGTM. > > Since you are planning on making a v2, I think it's better if you check it > in right now to get it out of the way (it could be obvious anyway). I would, but it depends on the patch before -- "[PATCH 3/9] PR gdb/21226: Take DWARF stack value pieces from LSB end". (Maybe it wasn't clear, but the current code for handling DWARF stack values is slightly more broken than just not taking them from the correct end. It also uses the relic "addr_size" instead of the actual DWARF stack value size to determine whether the piece is contained in its underlying object. And if it's *partially* contained, like taking a 1MB piece from a 64-bit stack value, the current code accesses invalid memory anyway.) -- Andreas