From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 73778 invoked by alias); 15 Mar 2017 19:16:58 -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 73759 invoked by uid 89); 15 Mar 2017 19:16:56 -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=Hx-languages-length:2111 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, 15 Mar 2017 19:16:54 +0000 Received: from pps.filterd (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v2FJ8UTd035321 for ; Wed, 15 Mar 2017 15:16:54 -0400 Received: from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107]) by mx0a-001b2d01.pphosted.com with ESMTP id 2978e5hfgy-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 15 Mar 2017 15:16:53 -0400 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 15 Mar 2017 19:16:52 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 15 Mar 2017 19:16:49 -0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v2FJGnar27459796; Wed, 15 Mar 2017 19:16:49 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6BD3FAE055; Wed, 15 Mar 2017 19:16:31 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5C01AAE04D; Wed, 15 Mar 2017 19:16:31 +0000 (GMT) Received: from oc3748833570.ibm.com (unknown [9.152.213.194]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 15 Mar 2017 19:16:31 +0000 (GMT) Received: by oc3748833570.ibm.com (Postfix, from userid 1000) id EC8B7D83328; Wed, 15 Mar 2017 20:16:48 +0100 (CET) Subject: Re: [PATCH] Big-endian targets: Don't ignore offset into DW_OP_stack_value To: arnez@linux.vnet.ibm.com (Andreas Arnez) Date: Wed, 15 Mar 2017 19:16:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, jan.kratochvil@redhat.com (Jan Kratochvil) In-Reply-To: from "Andreas Arnez" at Mar 15, 2017 07:04:48 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17031519-0040-0000-0000-0000036407F2 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17031519-0041-0000-0000-00001F49155C Message-Id: <20170315191648.EC8B7D83328@oc3748833570.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-03-15_08:,, 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-1703150145 X-SW-Source: 2017-03/txt/msg00254.txt.bz2 Andreas Arnez wrote: > On Mon, Mar 13 2017, Ulrich Weigand wrote: > > Thinking about this more, maybe it would be clearer to swap around the > > two types, and have the semantics of the function be something like: > > > > /* Evaluate a location description, starting at DATA and with length > > SIZE, to find the current location of variable of TYPE in the > > context of FRAME. If SUBOBJ_TYPE is non-NULL, return instead the > > location of the subobject of type SUBOBJ_TYPE at byte offset > > SUBOBJ_BYTE_OFFSET within the variable of type TYPE. */ > > OK. Of course this increases the amount of change a bit. New patch > below. Well, yes ... I still think it is clearer overall in the end. > + /* Get type of pointed-to DIE. */ > + struct type *orig_type = dwarf2_fetch_die_type_sect_off (die, per_cu); > + > /* If pointed-to DIE has a DW_AT_location, evaluate it and return the > resulting value. Otherwise, it may have a DW_AT_const_value instead, > or it may've been optimized out. */ > if (baton.data != NULL) > - return dwarf2_evaluate_loc_desc_full (TYPE_TARGET_TYPE (type), frame, > - baton.data, baton.size, baton.per_cu, > + return dwarf2_evaluate_loc_desc_full (orig_type, frame, baton.data, Can orig_type ever be NULL here? It probably would not be a good idea to pass NULL as the type argument. > - if (byte_offset != 0) > + if (subobj_byte_offset != 0) > error (_("cannot use offset on synthetic pointer to register")); As an aside: now that we have the full object type, we may actually be able to lift that restriction (do a value_from_register on the full type, and then extract the subobject). Might be interesting to look into as a follow-on change ... > size_t n = TYPE_LENGTH (value_type (value)); > + size_t len = TYPE_LENGTH (subobj_type); > + size_t max = type != NULL ? TYPE_LENGTH (type) : n; As mentioned above, I don't think it makes sense to allow a NULL type here. Otherwise, this looks good to me. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com