From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3746 invoked by alias); 12 Jun 2014 15:47:34 -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 3732 invoked by uid 89); 12 Jun 2014 15:47:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 12 Jun 2014 15:47:32 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id A9B341161F6; Thu, 12 Jun 2014 11:47:30 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id toPNZyYyLkkN; Thu, 12 Jun 2014 11:47:30 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 71B3B1161A8; Thu, 12 Jun 2014 11:47:30 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 4E8F140F35; Thu, 12 Jun 2014 17:47:29 +0200 (CEST) Date: Thu, 12 Jun 2014 15:47:00 -0000 From: Joel Brobecker To: Keven Boell Cc: Keven Boell , gdb-patches@sourceware.org, sanimir.agovic@intel.com Subject: Re: [PATCH 01/23] dwarf: add dwarf3 DW_OP_push_object_address opcode Message-ID: <20140612154729.GE4730@adacore.com> References: <1401861266-6240-1-git-send-email-keven.boell@intel.com> <1401861266-6240-2-git-send-email-keven.boell@intel.com> <20140610095445.GA5259@adacore.com> <53984AE9.7020200@linux.intel.com> <20140611130815.GC4709@adacore.com> <53995BFA.60109@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53995BFA.60109@linux.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2014-06/txt/msg00506.txt.bz2 > But this would still require the address to be communicated to the > property evaluation functions as the type still needs to be resolved > using resolve_dynamic_type. Usually resolve_dynamic_type will be called > through value_from_contents_and_address, which generates you a resolve > type in a value object. Do you have a concrete Fortran code example, > where you think the current implementation might go wrong? I think we're talking past each other :-(, so I'll try to explain in more details what I have in mind. I do not have any concrete Fortran example for you, and I am not saying that the implementation is wrong. I am asking a question of how things should work if the object you are trying to evaluate and resolve actually does not live in memory. If the object does not live in memory (eg: lives in register), are we stuck? The answer might be yes, or maybe that's something that can't happen, but I would like to explore that question to have a better understanding of what we can expect to achieve. Ideally, I have a feeling that what we should be taking isn't an address, but a struct value. The struct value object carries much more information, and might allow us to deal with the case above. Another interesting, and perhaps more likely scenario, is the case where part of the object is optimized out. You can't expect a "contents and address" to represent accurately your object, so chances are GDB would get it wrong. And the concrete situation that triggered all these questions is code in ada-lang.c. Take for instance ada_array_bound, which takes an unresolved array as a struct value (ARR), and returns the lower/higher bound for the nth dimension: ada_array_bound (struct value *arr, int n, int which) The function essentially finds ARR's N'th index type and calls resolve_dynamic_type on that type. If you actually look at the code, it's slightly indirect, but it's the idea. ada_array_bound -> ada_array_bound_from_type -> ada_discrete_type_high_bound -> resolve_dynamic_type Now, what address am I supposed to pass to resolve_dynamic_type? The simple answer would be "the address of the array", but then, we get back to the question I have been trying to ask: ARR may not be an lval_memory, in which case "the address of the array" is meaningless. And reducing a struct value back to an address feels like information degradation. To give even more context, I know there are bugs in GDB I can't fix until I convert it from contents-and-address to values, except the conversion appears hard to do on its own. So, I think it's worth pausing on this a little, and try to think things through before we decide that, indeed, an address is sufficient for our expected needs. -- Joel