From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 69138 invoked by alias); 23 Oct 2015 16:47:42 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 69127 invoked by uid 89); 23 Oct 2015 16:47:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,RP_MATCHES_RCVD,SPF_PASS autolearn=no version=3.3.2 X-HELO: e06smtp15.uk.ibm.com Received: from e06smtp15.uk.ibm.com (HELO e06smtp15.uk.ibm.com) (195.75.94.111) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Fri, 23 Oct 2015 16:47:40 +0000 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 23 Oct 2015 17:47:37 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 23 Oct 2015 17:47:36 +0100 X-IBM-Helo: d06dlp03.portsmouth.uk.ibm.com X-IBM-MailFrom: uweigand@de.ibm.com X-IBM-RcptTo: gdb@sourceware.org Received: from b06cxnps3075.portsmouth.uk.ibm.com (d06relay10.portsmouth.uk.ibm.com [9.149.109.195]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id DC5ED1B08069 for ; Fri, 23 Oct 2015 17:47:44 +0100 (BST) Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t9NGlaZE66453676 for ; Fri, 23 Oct 2015 16:47:36 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 t9NGlZCH007894 for ; Fri, 23 Oct 2015 10:47:35 -0600 Received: from oc7340732750.ibm.com (icon-9-164-153-39.megacenter.de.ibm.com [9.164.153.39]) by d06av03.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t9NGlY35007888; Fri, 23 Oct 2015 10:47:34 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 4798E6160; Fri, 23 Oct 2015 18:47:34 +0200 (CEST) Subject: Re: dynamic array's upper bound evaluated as address for AVR target To: derodat@adacore.com (Pierre-Marie de Rodat) Date: Fri, 23 Oct 2015 16:47:00 -0000 From: "Ulrich Weigand" Cc: brobecker@adacore.com (Joel Brobecker), Pitchumani.Sivanupandi@atmel.com (Sivanupandi Pitchumani), gdb@sourceware.org (gdb@sourceware.org), andrew.burgess@embecosm.com (Andrew Burgess), tom@tromey.com (tom@tromey.com) In-Reply-To: <562A41EA.6020304@adacore.com> from "Pierre-Marie de Rodat" at Oct 23, 2015 10:19:22 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20151023164734.4798E6160@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15102316-0021-0000-0000-000007B8B4BF X-SW-Source: 2015-10/txt/msg00097.txt.bz2 Pierre-Marie de Rodat wrote: > Quick update: I started to dig into this. I still have a hard time > wrapping the current implementation in my mind[1] and thinking about > what we should do exactly: > > * Have different types for expressions and location lists (hence > potentially renaming existing code): looks like a big commit! > > * Introduce another entry point to evaluate dynamic properties as > expressions. Looks like a small change but a weaker design: how to > evaluate depends a property depends on the property, not the evaluation > context, so it would be great to keep types distinct. > > I cannot make any commitment on a schedule to implement this, though. It seems to me the easiest path to implement the change incrementally might be: a.) We currently have: enum dynamic_prop_kind { PROP_UNDEFINED, /* Not defined. */ PROP_CONST, /* Constant. */ PROP_ADDR_OFFSET, /* Address offset. */ PROP_LOCEXPR, /* Location expression. */ PROP_LOCLIST /* Location list. */ }; As a first step, add a value PROP_EXPR /* DWARF expression. */ to this list. b.) Add code to dwarf2_evaluate_property / dwarf2_compile_property_to_c to support PROP_EXPR. This is a bit tricky since there is no real infrastructure to evaluate DWARF expressions, as opposed to location expressions. Note that the existing routine dwarf_entry_parameter_to_value uses the trick to append DW_OP_stack_value to the expression to force evaluation as a DWARF expression instead of location. The same could probably be done here. c.) For the range-related dynamic properties, create PROP_EXPR property nodes instead of PROP_LOC* property nodes. This probably means splitting the routine attr_to_dynamic_prop into two variants, one for locations and one for dynamic properties. -- At this point, everything should be functionally correct, the rest is simply cleanup --- d.) Create some new common mechanism to handle DWARF locations e.) Change the various places where DWARF locations are handled to use this new common mechanism: - DW_AT_location [ currently uses SYMBOL_COMPUTED_OPS ] - DW_AT_frame_base [ currently uses SYMBOL_BLOCK_OPS ] - DW_AT_data_location [ currently uses dynamic_prop ] - DW_AT_static_link [ currently uses dynamic_prop ] f.) Finally, remove (now unused) support for PROP_LOCEXPR/PROP_LOCLIST from the dynamic property code. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com