From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1802 invoked by alias); 17 Jun 2014 13:52:29 -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 1787 invoked by uid 89); 17 Jun 2014 13:52:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mga01.intel.com Received: from mga01.intel.com (HELO mga01.intel.com) (192.55.52.88) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Jun 2014 13:52:27 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 17 Jun 2014 06:52:25 -0700 X-ExtLoop1: 1 Received: from kboell-mobl2.ger.corp.intel.com (HELO [172.28.205.55]) ([172.28.205.55]) by fmsmga002.fm.intel.com with ESMTP; 17 Jun 2014 06:47:58 -0700 Message-ID: <53A0470E.9050206@linux.intel.com> Date: Tue, 17 Jun 2014 13:52:00 -0000 From: Keven Boell User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Joel Brobecker 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 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> <20140612154729.GE4730@adacore.com> In-Reply-To: <20140612154729.GE4730@adacore.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00582.txt.bz2 > I think we're talking past each other :-(, so I'll try to explain > in more details what I have in mind. Yes, I think so, sorry for that :( > > 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. We tried to follow the DWARF standard to get this implemented. The DWARF standard says that this scenario cannot happen in combination with the DW_OP_push_object_address operation: "The DW_OP_push_object_address operation pushes the _address_ of the object currently being evaluated as part of evaluation of a user presented expression [...] This operator provides explicit functionality (especially for arrays involving descriptors) that is analogous to the implicit push of the base address of a structure prior to evaluation of a DW_AT_data_member_location to access a data member of a structure." DWARF Debugging Information Format, Version 4. So I think having only the address here seems to be ok. > > 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. I agree with you that having a struct value instead of an address gives more flexibility, but for now I think this is not required according to the DWARF standard. If there is a real-world use-case where a full struct value object is required instead of having only the address, then this functionality can be added after this patch series. The patch series has been outdated, due to the introduction of two new functions by Tom (resolve_dynamic_struct and resolve_dynamic_union). Shall I therefore submit version 2? Keven