From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127107 invoked by alias); 4 Sep 2018 21:54:56 -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 127097 invoked by uid 89); 4 Sep 2018 21:54:55 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 04 Sep 2018 21:54:54 +0000 Received: from smtp.corp.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 5C5BE9E606; Tue, 4 Sep 2018 21:54:53 +0000 (UTC) Received: from pinnacle.lan (ovpn-116-195.phx2.redhat.com [10.3.116.195]) by smtp.corp.redhat.com (Postfix) with ESMTPS id F36572010CAB; Tue, 4 Sep 2018 21:54:52 +0000 (UTC) Date: Tue, 04 Sep 2018 21:54:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Tom de Vries Subject: Re: [PATCH, gdb/exp] Handle DW_OP_GNU_variable_value refs to abstract dies Message-ID: <20180904145449.2cf6a099@pinnacle.lan> In-Reply-To: <95697ec8-30e2-acaf-60fd-e46524f88e72@suse.de> References: <20180802210405.5c04ca7a@pinnacle.lan> <20180802211754.40a529c2@pinnacle.lan> <87o9ej1emk.fsf@tromey.com> <20180818133158.7e5b4dcb@pinnacle.lan> <93529546-71b0-4268-880a-79b00062ecd2@suse.de> <20180823141240.577345e0@pinnacle.lan> <982919b5-93ba-3840-5839-6accc904b459@suse.de> <5e6ac298-bf8f-6957-984a-67bb58b62be9@suse.de> <95697ec8-30e2-acaf-60fd-e46524f88e72@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-09/txt/msg00061.txt.bz2 Hi Tom, Thank you for doing this work. It looks mostly okay, though I do have a few comments... Kevin On Tue, 4 Sep 2018 15:06:34 +0200 Tom de Vries wrote: > 2018-09-04 Tom de Vries > > * dwarf2loc.c (sect_variable_value): Call indirect_synthetic_pointer > with resolve_abstract_p == true. > (indirect_synthetic_pointer): Add resolve_abstract_p parameter, > defaulting to false. Propagate resolve_abstract_p to > dwarf2_fetch_die_loc_sect_off. > * dwarf2loc.h (dwarf2_fetch_die_loc_sect_off): Add resolve_abstract_p > parameter, defaulting to false. > * dwarf2read.c (dwarf2_per_objfile::~dwarf2_per_objfile): Reset > abstract_to_concrete. > (read_variable): Add variable to abstract_to_concrete. > (dwarf2_fetch_die_loc_sect_off): Add and handle resolve_abstract_p > parameter. > * dwarf2read.h (struct die_info): Forward-declare. > (die_info_ptr): New typedef. > (DEF_VEC_P (die_info_ptr)): Add. > (struct dwarf2_per_objfile): Add abstract_to_concrete field. > > * gdb.dwarf2/varval.exp: Add test. > > --- > gdb/dwarf2loc.c | 10 ++++--- > gdb/dwarf2loc.h | 2 +- > gdb/dwarf2read.c | 56 +++++++++++++++++++++++++++++++++++-- > gdb/dwarf2read.h | 6 ++++ > gdb/testsuite/gdb.dwarf2/varval.exp | 22 ++++++++++++++- > 5 files changed, 88 insertions(+), 8 deletions(-) > > diff --git a/gdb/dwarf2loc.c b/gdb/dwarf2loc.c > index 200fa03f46..a75eb158c7 100644 > --- a/gdb/dwarf2loc.c > +++ b/gdb/dwarf2loc.c > @@ -65,7 +65,7 @@ static struct value *indirect_synthetic_pointer > (sect_offset die, LONGEST byte_offset, > struct dwarf2_per_cu_data *per_cu, > struct frame_info *frame, > - struct type *type); > + struct type *type, bool = false); Please add a name for the new bool parameter. > diff --git a/gdb/dwarf2loc.h b/gdb/dwarf2loc.h > index f82e7b2d11..08120651b6 100644 > --- a/gdb/dwarf2loc.h > +++ b/gdb/dwarf2loc.h > @@ -67,7 +67,7 @@ const gdb_byte *dwarf2_find_location_expression > struct dwarf2_locexpr_baton dwarf2_fetch_die_loc_sect_off > (sect_offset offset_in_cu, struct dwarf2_per_cu_data *per_cu, > CORE_ADDR (*get_frame_pc) (void *baton), > - void *baton); > + void *baton, bool = false); Likewise, here. > diff --git a/gdb/dwarf2read.h b/gdb/dwarf2read.h > index 13855bcd54..71ef781d17 100644 > --- a/gdb/dwarf2read.h > +++ b/gdb/dwarf2read.h > @@ -20,6 +20,7 @@ > #ifndef DWARF2READ_H > #define DWARF2READ_H > > +#include > #include "dwarf-index-cache.h" > #include "filename-seen-cache.h" > #include "gdb_obstack.h" > @@ -95,6 +96,9 @@ struct dwarf2_debug_sections; > struct mapped_index; > struct mapped_debug_names; > struct signatured_type; > +struct die_info; > +typedef struct die_info *die_info_ptr; > +DEF_VEC_P (die_info_ptr); > > /* Collection of data recorded per objfile. > This hangs off of dwarf2_objfile_data_key. */ > @@ -250,6 +254,8 @@ public: > /* If we loaded the index from an external file, this contains the > resources associated to the open file, memory mapping, etc. */ > std::unique_ptr index_cache_res; > + > + std::unordered_map abstract_to_concrete; > }; Is there a good reason to use VEC instead of std::vector? I know that there have been a number of patches which have been replacing VEC with std:vector. So, unless there's a compelling reason to use VEC, we might as well use std:vector here and save someone else the effort of changing this use of VEC later on. Also, can you add a comment for abstract_to_concrete? Kevin