From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87036 invoked by alias); 13 Oct 2015 14:44:03 -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 85867 invoked by uid 89); 13 Oct 2015 14:44:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 13 Oct 2015 14:44:01 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 44983279D8B6; Tue, 13 Oct 2015 16:43:58 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vmuId-2WrfSY; Tue, 13 Oct 2015 16:43:58 +0200 (CEST) Received: from [10.10.1.112] (cacatoes.act-europe.fr [10.10.1.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 90AAF279D7DE; Tue, 13 Oct 2015 16:43:57 +0200 (CEST) Subject: Re: dynamic array's upper bound evaluated as address for AVR target To: "Sivanupandi, Pitchumani" , "gdb@sourceware.org" References: Cc: Andrew Burgess , "tom@tromey.com" , "uweigand@de.ibm.com" From: Pierre-Marie de Rodat Message-ID: <561D18AD.6080701@adacore.com> Date: Tue, 13 Oct 2015 14:44:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00062.txt.bz2 Pitchumani, (chiming in because I’ve worked a bit on DWARF expressions in GDB, but disclaimer: I’m not a maintainer ;-)) On 10/13/2015 11:07 AM, Sivanupandi, Pitchumani wrote: > Why is that location expression treated as DWARF_VALUE_MEMORY by default? > Can gdb detect if location expression for literal value (e.g. array bounds) > or not? struct dwarf_expr_context::location is relevant only when evaluating DWARF expressions which are location descriptions. These descriptions generally compute addresses for objects but this “location” field makes it possible to describe objects that are not in memory (for instance in registers or several pieces in different places). Anyway in the case you expose, the DWARF expressions compute bounds (i.e. scalar values) and thus this field is not relevant[1]. I was not aware of this hook (integer_to_address) and I could not find relevant documentation to learn about what it means, in what specific cases it should be used/avoided and why it exists in the first place (not being familiar with AVR neither, I don't understand what the corresponding code in avr-tdep.c does), so the following is speculation. dwarf2_locexpr_baton_eval evaluates a DWARF expression assuming it computes the address of an object[1] and thus ends up invoking this hook. So my understanding is that either we should not call dwarf2_locexpr_baton_eval when evaluating things that are not locations (such as subrange bounds), either we should adapt dwarf2_locexpr_baton_eval to accept a new parameter telling wether the caller wants an address or a scalar. Thoughts? [1] This makes me feel like the handling of everything that is not DWARF_VALUE MEMORY in this function is dead (and incorrect) code: we should not get anything else in this context. I checked what happens when evaluating expressions in a GDB session: dwarf2_evaluate_loc_desc_full is called to get the location of objects, not dwarf2_locexpr_baton_eval. I tried to remove stack/register/literal handling and had no testsuite regression. -- Pierre-Marie de Rodat