From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118286 invoked by alias); 15 Oct 2019 16:27:48 -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 118261 invoked by uid 89); 15 Oct 2019 16:27:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=sk:inherit, Kevin, kevin, *die 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, 15 Oct 2019 16:27:45 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E8D3410DCC81; Tue, 15 Oct 2019 16:27:43 +0000 (UTC) Received: from f29-4.lan (ovpn-118-26.phx2.redhat.com [10.3.118.26]) by smtp.corp.redhat.com (Postfix) with ESMTPS id BED995D6B7; Tue, 15 Oct 2019 16:27:43 +0000 (UTC) Date: Tue, 15 Oct 2019 16:27:00 -0000 From: Kevin Buettner To: gdb-patches@sourceware.org Cc: Simon Marchi Subject: Re: [PATCH 1/2] Fix BZ 25065 - Ensure that physnames are computed for inherited DIEs Message-ID: <20191015092743.7037f47c@f29-4.lan> In-Reply-To: <8c073683bc0b0a8e7918fdfb346cbb03@polymtl.ca> References: <20191014001842.27413-1-kevinb@redhat.com> <20191014001842.27413-2-kevinb@redhat.com> <8c073683bc0b0a8e7918fdfb346cbb03@polymtl.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00432.txt.bz2 On Sun, 13 Oct 2019 23:02:01 -0400 Simon Marchi wrote: > Hi Kevin, > > I don't really have the big picture of these advanced DWARF use cases, > so I can't really weigh on this, but I have a question: > > > diff --git a/gdb/dwarf2read.c b/gdb/dwarf2read.c > > index ee9df34ed2..f7ef122933 100644 > > --- a/gdb/dwarf2read.c > > +++ b/gdb/dwarf2read.c > > @@ -13666,6 +13666,17 @@ inherit_abstract_dies (struct die_info *die, > > struct dwarf2_cu *cu) > > origin_child_die = sibling_die (origin_child_die); > > } > > origin_cu->list_in_scope = origin_previous_list_in_scope; > > + > > + if (cu != origin_cu && !origin_cu->method_list.empty ()) > > + { > > + /* Add list of methods found in origin_cu to the list in cu. > > These > > + methods still need to have their physnames computed in > > + compute_delayed_physnames(). */ > > + cu->method_list.insert (cu->method_list.end (), > > + origin_cu->method_list.begin (), > > + origin_cu->method_list.end ()); > > + origin_cu->method_list.clear (); > > + } > > So, this effectively makes the inheriting CU steal the method_list > content from the inherited from CU? Is it possible for a CU to be > inherited from multiple times? If so, what happens the second time we > process something that inherits from this CU, the method_list vector > will then be empty? Is it that we want? Hi Simon, You raise some good questions. I modified the test associated with this bug so that two different CUs attempt to inherit a third CU. This has turned up another bug in GDB which I spent the rest of the day looking at. (GDB goes into an infinite loop!) I'll make the following observations, however... - method_list is used solely for keeping track of C++ methods for delayed physname computations. - method_list is cleared in process_full_comp_unit(), process_full_type_unit(), and compute_delayed_physnames(). That latter function(), compute_delayed_physnames(), is called after DIE processing in the first two functions. So method_list is made to be empty prior to DIE processing and then made empty (as a result of delayed physname computation) again after DIE processing (in the above mentioned functions). So, what is the right thing to do with regard to method_list for inherit_abstract_dies()? Yesterday, as part of my investigations, I made inherit_abstract_dies() call compute_delayed_physnames in place of the code in my posted patch. That also works, at least for my test case. I'll note that for my original (posted) patch, compute_delayed_physnames will be called with the inheriting CU. In the alternate approach (in which compute_delayed_physnames is called from inherit_abstract_dies), compute_delayed_physnames is called with the origin CU. I don't yet know which is more correct or if there are cases where it'll make a difference. So... I'm continuing my investigations and will let you know when I have some answers. In the interim, if anyone has some insights about these matters, I'd very much like to hear them. Kevin