From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 116640 invoked by alias); 14 Nov 2016 16:38:41 -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 116625 invoked by uid 89); 14 Nov 2016 16:38:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SEMBACKSCATTER,SPF_PASS autolearn=ham version=3.3.2 spammy=resides 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; Mon, 14 Nov 2016 16:38:39 +0000 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uAEGXq2P061373 for ; Mon, 14 Nov 2016 11:38:38 -0500 Received: from e06smtp13.uk.ibm.com (e06smtp13.uk.ibm.com [195.75.94.109]) by mx0a-001b2d01.pphosted.com with ESMTP id 26qfda5et6-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Nov 2016 11:38:38 -0500 Received: from localhost by e06smtp13.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 14 Nov 2016 16:38:35 -0000 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp13.uk.ibm.com (192.168.101.143) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Mon, 14 Nov 2016 16:38:33 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp01.portsmouth.uk.ibm.com (Postfix) with ESMTP id B804B17D805F for ; Mon, 14 Nov 2016 16:40:56 +0000 (GMT) Received: from d06av09.portsmouth.uk.ibm.com (d06av09.portsmouth.uk.ibm.com [9.149.37.250]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uAEGcXCa42401828 for ; Mon, 14 Nov 2016 16:38:33 GMT Received: from d06av09.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id uAEGcWEI030470 for ; Mon, 14 Nov 2016 09:38:33 -0700 Received: from oc8523832656.ibm.com (dyn-9-152-213-198.boeblingen.de.ibm.com [9.152.213.198]) by d06av09.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id uAEGcWgY030467; Mon, 14 Nov 2016 09:38:32 -0700 Received: by oc8523832656.ibm.com (Postfix, from userid 500) id 3C14F10B924; Mon, 14 Nov 2016 17:38:32 +0100 (CET) Subject: Re: set_value_component_location in apply_val_pretty_printer To: qiyaoltc@gmail.com (Yao Qi) Date: Mon, 14 Nov 2016 16:38:00 -0000 From: "Ulrich Weigand" Cc: user-agent@de.ibm.com;, bh=bRSZrFs7MDCHH9pBZWPVTfOSNPe/nJuj407ynYvPgXM=@de.ibm.com;, b=Ad2ef64JwNZkXMSBRIw9rjjbKD3TRg5+F7YP3OvdCo7XdZIOHnnX9P8Bq+YX6BV2SWCHunVt2nVkgOreg4Sj2rsH9OrG70EvWdRw3lMXWWl8e5E7+T17MKumAdjj+9kxYu1c5oc1/CeW7UG444M/MDt+GN+Db@gmail.com, gdb-patches@sourceware.org (gdb-patches@sourceware.org), tom@tromey.com (Tom Tromey) In-Reply-To: <20161114125143.GA22037@E107787-LIN> from "Yao Qi" at Nov 14, 2016 12:51:43 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: 16111416-0012-0000-0000-0000048AD210 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16111416-0013-0000-0000-000016344B8F Message-Id: <20161114163832.3C14F10B924@oc8523832656.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-11-14_09:,, 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-1611140335 X-SW-Source: 2016-11/txt/msg00344.txt.bz2 Yao Qi wrote: > On Fri, Oct 28, 2016 at 08:58:33PM +0200, Ulrich Weigand wrote: > > But this isn't really correct either, since we need the > > location of the *subobject*. Now if the value resides > > in inferior memory, we can get there simply by adding > > the offset to the value address. But that's not actually > > correct for values with other location types. > > I don't see why it is not correct to set the value's location to the same as > the location of old. The 'whole' object and 'component' object should have > the same location with different offsets (internalvar is an exception since > the component's location is interanlvar_component), so > set_value_component_location looks right to me. I think in the past we have avoided using value_offset for lval_memory values for some reason. It's been used only for values in registers (or other non-memory values). I'm not really sure why this is the case -- maybe value_offset isn't always taken into account everywhere? But maybe it is indeed the best way to use value_offset for creating subobjects, and if there's any fallout, just fix that. (In the alternative, we might use value_offset for non-lval_memory values, and just increment the address for lval_memory ones ...). B.t.w. I noticed that the bottom half of value_subscripted_rvalue now looks very similar to your new value_from_component routine; maybe it ought to be used there too. Otherwise the patch looks good to me. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com