From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53090 invoked by alias); 22 Nov 2016 18:16:25 -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 53078 invoked by uid 89); 22 Nov 2016 18:16:24 -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=Hx-languages-length:2181, solely, hey 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; Tue, 22 Nov 2016 18:16:23 +0000 Received: from pps.filterd (m0098413.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uAMIDV8m086371 for ; Tue, 22 Nov 2016 13:16:22 -0500 Received: from e06smtp09.uk.ibm.com (e06smtp09.uk.ibm.com [195.75.94.105]) by mx0b-001b2d01.pphosted.com with ESMTP id 26vse6fyw6-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 22 Nov 2016 13:16:21 -0500 Received: from localhost by e06smtp09.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 22 Nov 2016 18:16:19 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp09.uk.ibm.com (192.168.101.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 22 Nov 2016 18:16:17 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id D17381B08023 for ; Tue, 22 Nov 2016 18:18:35 +0000 (GMT) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uAMIGHS923331018 for ; Tue, 22 Nov 2016 18:16:17 GMT Received: from d06av03.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id uAMIGG5Q009365 for ; Tue, 22 Nov 2016 11:16:17 -0700 Received: from oc8523832656.ibm.com (dyn-9-152-213-198.boeblingen.de.ibm.com [9.152.213.198]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id uAMIGGhC009362; Tue, 22 Nov 2016 11:16:16 -0700 Received: by oc8523832656.ibm.com (Postfix, from userid 500) id 118F810B923; Tue, 22 Nov 2016 19:16:16 +0100 (CET) Subject: Re: [PATCH 1/3] New function value_has_address To: palves@redhat.com (Pedro Alves) Date: Tue, 22 Nov 2016 18:16:00 -0000 From: "Ulrich Weigand" Cc: brobecker@adacore.com (Joel Brobecker), qiyaoltc@gmail.com (Yao Qi), gdb-patches@sourceware.org In-Reply-To: from "Pedro Alves" at Nov 22, 2016 05:56:07 PM 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: 16112218-0036-0000-0000-00000264D844 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16112218-0037-0000-0000-0000135C9350 Message-Id: <20161122181616.118F810B923@oc8523832656.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-22_10:,, 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-1611220319 X-SW-Source: 2016-11/txt/msg00650.txt.bz2 Pedro Alves wrote: > On 11/22/2016 04:50 PM, Joel Brobecker wrote: > > Hey Yao, > > > >> +/* Return true if VALUE has address, otherwise return false. */ > >> + > >> +static int > >> +value_has_address (const struct value *value) > >> +{ > >> + return (value->lval != lval_internalvar > >> + && value->lval != lval_internalvar_component > >> + && value->lval != lval_xcallable); > > > > I'm wondering about the function's name. Does a value that > > lives in a register, for instance, really have an address? > > For me, if there was a function value_has_address, it would > > return nonzero only for lval_memory. I'm not too sure if > > lval_computed would qualify or not. > > > > Perhaps, what you were looking for, is something like > > value_lives_in_inferior? > > The intention of the function is to return true if the value > uses the value.location.address union field as location: > > /* Location of value (if lval). */ > union > { > /* If lval == lval_memory, this is the address in the inferior. > If lval == lval_register, this is the byte offset into the > registers structure. */ > CORE_ADDR address; > ... > } location; > > 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. 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 ... Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com