From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50144 invoked by alias); 14 Oct 2015 09:41:51 -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 50130 invoked by uid 89); 14 Oct 2015 09:41:50 -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,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: e06smtp11.uk.ibm.com Received: from e06smtp11.uk.ibm.com (HELO e06smtp11.uk.ibm.com) (195.75.94.107) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (CAMELLIA256-SHA encrypted) ESMTPS; Wed, 14 Oct 2015 09:41:49 +0000 Received: from localhost by e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 14 Oct 2015 10:41:46 +0100 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 14 Oct 2015 10:41:44 +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 7BD4A1B08061 for ; Wed, 14 Oct 2015 10:41:48 +0100 (BST) Received: from d06av11.portsmouth.uk.ibm.com (d06av11.portsmouth.uk.ibm.com [9.149.37.252]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id t9E9fhRc31064064 for ; Wed, 14 Oct 2015 09:41:43 GMT Received: from d06av11.portsmouth.uk.ibm.com (localhost [127.0.0.1]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id t9E9fh9m016505 for ; Wed, 14 Oct 2015 03:41:43 -0600 Received: from oc7340732750.ibm.com (icon-9-164-140-83.megacenter.de.ibm.com [9.164.140.83]) by d06av11.portsmouth.uk.ibm.com (8.14.4/8.14.4/NCO v10.0 AVin) with ESMTP id t9E9fg83016477; Wed, 14 Oct 2015 03:41:42 -0600 Received: by oc7340732750.ibm.com (Postfix, from userid 500) id 54C93DAD; Wed, 14 Oct 2015 11:41:41 +0200 (CEST) Subject: Re: dynamic array's upper bound evaluated as address for AVR target To: derodat@adacore.com (Pierre-Marie de Rodat) Date: Wed, 14 Oct 2015 09:41:00 -0000 From: "Ulrich Weigand" Cc: Pitchumani.Sivanupandi@atmel.com (Sivanupandi Pitchumani), brobecker@adacore.com (Joel Brobecker), gdb@sourceware.org (gdb@sourceware.org), andrew.burgess@embecosm.com (Andrew Burgess), tom@tromey.com (tom@tromey.com) In-Reply-To: <561E11A2.5030206@adacore.com> from "Pierre-Marie de Rodat" at Oct 14, 2015 10:26:10 AM MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-Id: <20151014094141.54C93DAD@oc7340732750.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15101409-0041-0000-0000-00000625B039 X-SW-Source: 2015-10/txt/msg00067.txt.bz2 Pierre-Marie de Rodat wrote: > On 10/14/2015 09:54 AM, Sivanupandi, Pitchumani wrote: > >> Then maybe we should add this expect_address parameter to both > >> dwarf2_evaluate_property and dwarf2_locexpr_baton_eval… > > > > Ok. I'll try it out. > > Thank you! As I said previously, I’m not a maintainer: I added Joel as a > recipient since he’s both a maintainer and the original author of the > dwarf2 property mechanism. I've just had a quick look at the "dwarf2 property" mechanism, and it seems to me that our current implementation mixes up two different things. We currently use attr_to_dynamic_prop for three property types: DW_AT_lower_bound DW_AT_upper_bound DW_AT_count DW_AT_static_link DW_AT_data_location However, the DWARF standard describes the first three in a quite different manner than the latter two. For DW_AT_static_link, we have: If a subroutine or entry point is nested, it may have a DW_AT_static_link attribute, whose value is a location description that computes the frame base of the relevant instance of the subroutine that immediately encloses the subroutine or entry point. For DW_AT_data_location, we have: The DW_AT_data_location attribute may be used with any type that provides one or more levels of hidden indirection and/or run-time parameters in its representation. Its value is a location description. The result of evaluating this description yields the location of the data for an object. So those two are *location descriptions* that evaluate to an address. They should be treated just like DW_AT_frame_base is today, i.e. using the dwarf2_loclist_baton/dwarf2_locexpr_baton mechanism. On the other hand, for the first three attrbutes, the standard says: The subrange entry may have the attributes DW_AT_lower_bound and DW_AT_upper_bound to specify, respectively, the lower and upper bound values of the subrange. The DW_AT_upper_bound attribute may be replaced by a DW_AT_count attribute, whose value describes the number of elements in the subrange rather than the value of the last element. The value of each of these attributes is determined as described in Section 2.19. Where section 2.19 reads: Some attributes that apply to types specify a property (such as the lower bound of an array) that is an integer value, where the value may be known during compilation or may be computed dynamically during execution. The value of these attributes is determined based on the class as follows: • For a constant, the value of the constant is the value of the attribute. • For a reference, the value is a reference to another entity which specifies the value of the attribute. • For an exprloc, the value is interpreted as a DWARF expression; evaluation of the expression yields the value of the attribute. where the value may be a DWARF *expression*, but not a location description, and it results in an integer, not an address. Note that a plain DWARF expression can actually from a valid location description (namely a simple memory location expression), but there are many more options how a location description can look. I think the current GDB "dynamic property" mechanism was probably intended to capture what DWARF section 2.19 specifies, but due to its simultaneous use for DW_AT_data_location and DW_AT_static_link, things got confused. It would probably be best to clearly separate this out into two separate mechanisms, one that precisely implements dynamic properties as defined in section 2.19, and one that implements location descriptions. (Note that those mechanism should ideally then be used for some of the *other* places where the DWARF standard also allows either a dynamic property or a location description, but GDB doesn't accept them yet.) This would then have the side effect that we could distinguish return types: location descriptions always return an address, but section 2.19 dynamic attributes always return an integer. Bye, Ulrich -- Dr. Ulrich Weigand GNU/Linux compilers and toolchain Ulrich.Weigand@de.ibm.com