From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 68896 invoked by alias); 23 Nov 2016 12:50:19 -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 68881 invoked by uid 89); 23 Nov 2016 12:50:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=debate, solely X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0b-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.158.5) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Nov 2016 12:50:08 +0000 Received: from pps.filterd (m0098416.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uANCn3Xh102673 for ; Wed, 23 Nov 2016 07:50:06 -0500 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0b-001b2d01.pphosted.com with ESMTP id 26w6ybqqr2-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 23 Nov 2016 07:50:06 -0500 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 23 Nov 2016 12:50:04 -0000 Received: from d06dlp02.portsmouth.uk.ibm.com (9.149.20.14) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 23 Nov 2016 12:50:02 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp02.portsmouth.uk.ibm.com (Postfix) with ESMTP id 4ABD92190063 for ; Wed, 23 Nov 2016 12:49:14 +0000 (GMT) Received: from d06av05.portsmouth.uk.ibm.com (d06av05.portsmouth.uk.ibm.com [9.149.37.229]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uANCo1kA26607698 for ; Wed, 23 Nov 2016 12:50:01 GMT Received: from d06av05.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id uANCo1hM015958 for ; Wed, 23 Nov 2016 05:50:01 -0700 Received: from oc8523832656.ibm.com (dyn-9-152-213-198.boeblingen.de.ibm.com [9.152.213.198]) by d06av05.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id uANCo1Hl015936; Wed, 23 Nov 2016 05:50:01 -0700 Received: by oc8523832656.ibm.com (Postfix, from userid 500) id DBC6D10FB47; Wed, 23 Nov 2016 13:50:00 +0100 (CET) Subject: Re: [PATCH 1/3] New function value_has_address To: qiyaoltc@gmail.com (Yao Qi) Date: Wed, 23 Nov 2016 12:50:00 -0000 From: "Ulrich Weigand" Cc: user-agent@de.ibm.com;, bh=w3l5Ym541pvuwML9/6SKkkW70PlV/JFWNgp0ub7fEec=@de.ibm.com;, b=XnKcs0r3lZWx7Ceaf3Cswl5MRddHbb49TdlQOOMFuCfi2P9bEJYGh0qu/y0vrMWR87KF8NAAthSrdqry+pI4iDU6E3DFYkbF4i4s7zYh7DZwetUGtPlOgUUDR30ecLpPgE0PLwSeidueDbqooIodY+xzc2f8q@gmail.com, palves@redhat.com (Pedro Alves), brobecker@adacore.com (Joel Brobecker), gdb-patches@sourceware.org In-Reply-To: <20161123092621.GD24810@E107787-LIN> from "Yao Qi" at Nov 23, 2016 09:26:21 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16112312-0008-0000-0000-000003B014C0 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16112312-0009-0000-0000-00001B874969 Message-Id: <20161123125000.DBC6D10FB47@oc8523832656.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-23_01:,, 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-1609300000 definitions=main-1611230225 X-SW-Source: 2016-11/txt/msg00666.txt.bz2 Yao Qi wrote: > On Tue, Nov 22, 2016 at 07:16:15PM +0100, Ulrich Weigand wrote: > > > I think that it's good that the names match. If one is renamed, > > > so should the other, IMO. Maybe call the function > > > value_has_address_location? I think it'd be good if the > > > function's intro comment made this link more explicit. > > > Actually, I see now that patch #3 tweaks the comment. > > > > I think part of the confusion is that the comment above is simply > > no longer true; for lval_register values, address is *not* (any longer) > > used to hold any byte offset into a register structure, as far as I > > can see. Instead, for lval_register values, the register that holds > > the value is identifed solely via the VALUE_REGNUM/VALUE_NEXT_FRAME_ID > > fields, and the address field is ignored. > > That is what I am saying in the last paragraph of cover letter. I see, I missed that. I think given that we really only ever should use value.location.address on lval_memory values, maybe the clearest way would be to guard accesses with an explicit VALUE_LVAL == lval_memory check instead of moving that check to a function. Then we don't have to debate how that function should be called either :-) > > I think we should reword the comments to reflect the fact that > > "address" is only used for lval_address. On the other hand, > > the regnum/frame_id fields should move into the union and only > > be used for lval_register values ... > > > > That is what I am trying to do in next step. Let me finish it and > include it in this series as well. Very good, thanks! [ B.t.w. I noticed one more case of fields that probably ought to move into the location union: value.parent, .bitsize, and .bitpos are only ever used for bitfields. Maybe we should create a new lval_component (possibly renamed from lval_internalval_component) that uses those three fields as location; where all further data is retrieved from the parent value. But that's certainly another independent change ... ] Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com