From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3663 invoked by alias); 28 Oct 2016 18:58:46 -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 3646 invoked by uid 89); 28 Oct 2016 18:58:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=fresh 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; Fri, 28 Oct 2016 18:58:43 +0000 Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u9SIwg8m093207 for ; Fri, 28 Oct 2016 14:58:42 -0400 Received: from e06smtp09.uk.ibm.com (e06smtp09.uk.ibm.com [195.75.94.105]) by mx0a-001b2d01.pphosted.com with ESMTP id 26cam2febt-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 28 Oct 2016 14:58:41 -0400 Received: from localhost by e06smtp09.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 28 Oct 2016 19:58:36 +0100 Received: from d06dlp01.portsmouth.uk.ibm.com (9.149.20.13) by e06smtp09.uk.ibm.com (192.168.101.139) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 28 Oct 2016 19:58:35 +0100 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 2C3AF17D8024 for ; Fri, 28 Oct 2016 20:00:51 +0100 (BST) Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u9SIwZak42074250 for ; Fri, 28 Oct 2016 18:58:35 GMT Received: from d06av01.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u9SIwZZd028987 for ; Fri, 28 Oct 2016 12:58:35 -0600 Received: from oc8523832656.ibm.com (icon-9-164-186-41.megacenter.de.ibm.com [9.164.186.41]) by d06av01.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id u9SIwYBE028984; Fri, 28 Oct 2016 12:58:35 -0600 Received: by oc8523832656.ibm.com (Postfix, from userid 500) id 0145C10B927; Fri, 28 Oct 2016 20:58:33 +0200 (CEST) Subject: Re: set_value_component_location in apply_val_pretty_printer To: qiyaoltc@gmail.com (Yao Qi) Date: Fri, 28 Oct 2016 18:58:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org (gdb-patches@sourceware.org), tom@tromey.com (Tom Tromey) In-Reply-To: from "Yao Qi" at Oct 28, 2016 03:18:33 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: 16102818-0036-0000-0000-0000024EC330 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16102818-0037-0000-0000-0000130BA79E Message-Id: <20161028185834.0145C10B927@oc8523832656.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-10-28_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-1609300000 definitions=main-1610280321 X-SW-Source: 2016-10/txt/msg00823.txt.bz2 Yao Qi wrote: > I don't understand this piece of code in apply_val_pretty_printer, > why do we need to call set_value_component_location? > > set_value_component_location (value, val); > /* set_value_component_location resets the address, so we may > need to set it again. */ > if (VALUE_LVAL (value) !=3D lval_internalvar > && VALUE_LVAL (value) !=3D lval_internalvar_component > && VALUE_LVAL (value) !=3D lval_computed) > set_value_address (value, address + embedded_offset); > > It was added by Tom in > https://sourceware.org/ml/gdb-patches/2010-06/msg00132.html > There wasn't much information in email and ChangeLog. This the case I mentioned in my recent email to Pedro here, where we want to create a subobject of the original object. The problem with the value printing routines is that if you are printing an object of some complicated type, the routines recurse through subobjects. However, you don't always want to allocate a new value object for the current subobject just so you can make the recursive call. That's why all the val_print routines not just receive the original value object (which remains unchanged even while recursing through subobjects), but also an idenfication of the subobject that is to be processed: this is a pair of offset and type, and means, the subobject of type "type" starting at offset "offset" within the larger object. This works fine for the various routines in the valprint files. However, when using a Python pretty-printer, you can only pass a normal value object; the pretty-printer is not set up to handle subobjects. Therefore, at this point apply_val_pretty_printer does actually have to allocate a new value object to hold the subobject. It's reasonably simple to just create a new object of the correct type and having the correct contents. However, some of the value printers also want to use the value's *location*. Just allocating a fresh object would have no location information. That's why the code above calls set_value_component_location to set the location of the new value to the same as the location of the old. 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 think we should either add an offset parameter to set_value_component_location, and have it attempt to do the best thing possible to describe the subobject location, or maybe even provide a function that creates the subobject directly in one go, along the lines of value_primitive_field, except not based on struct types but simply using an offset and subobject type. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com