From patchwork Thu Jan 23 00:57:00 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tom Tromey X-Patchwork-Id: 37500 Received: (qmail 83018 invoked by alias); 23 Jan 2020 00:57:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 80957 invoked by uid 89); 23 Jan 2020 00:57:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-21.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_PASS autolearn=ham version=3.3.1 spammy=price, pay X-HELO: gateway20.websitewelcome.com Received: from gateway20.websitewelcome.com (HELO gateway20.websitewelcome.com) (192.185.62.46) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 23 Jan 2020 00:57:27 +0000 Received: from cm16.websitewelcome.com (cm16.websitewelcome.com [100.42.49.19]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 82311400C8B40 for ; Wed, 22 Jan 2020 17:44:53 -0600 (CST) Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with SMTP id uQoIiPju532AduQoIiZGPM; Wed, 22 Jan 2020 18:57:26 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Sender:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=a9FRR/+OIfMvt8yPla3gVLTLt23j7GI/V9r/5p4yjBQ=; b=RovJeQ+bLMogx864Ld3yYgg5XE y8IGjX0kS3asSshrwdHbTJcBSEYufVSBl1mSbcdwxMxzctscQI2eRisCVxGwnk1JokR5VaZ7M3j7v 2Yy4tSRTondDdHgdPa0L5yy40; Received: from 75-166-123-50.hlrn.qwest.net ([75.166.123.50]:40828 helo=bapiya.Home) by box5379.bluehost.com with esmtpa (Exim 4.92) (envelope-from ) id 1iuQoI-004Kmd-Cq; Wed, 22 Jan 2020 17:57:26 -0700 From: Tom Tromey To: gdb-patches@sourceware.org Cc: Tom Tromey Subject: [PATCH 28/38] Move dwarf2_per_cu_data::imported_symtabs earlier Date: Wed, 22 Jan 2020 17:57:00 -0700 Message-Id: <20200123005710.7978-29-tom@tromey.com> In-Reply-To: <20200123005710.7978-1-tom@tromey.com> References: <20200123005710.7978-1-tom@tromey.com> This moves dwarf2_per_cu_data::imported_symtabs earlier, near where the other data members are located. 2020-01-22 Tom Tromey * dwarf2/read.h (struct dwarf2_per_cu_data) : Move earlier. Change-Id: I314ddaa6f67c53a848e513b3f6d42913bd957833 --- gdb/ChangeLog | 5 +++++ gdb/dwarf2/read.h | 52 +++++++++++++++++++++++------------------------ 2 files changed, 31 insertions(+), 26 deletions(-) diff --git a/gdb/dwarf2/read.h b/gdb/dwarf2/read.h index 9eab657e14a..646a53fadd2 100644 --- a/gdb/dwarf2/read.h +++ b/gdb/dwarf2/read.h @@ -317,6 +317,32 @@ struct dwarf2_per_cu_data struct dwarf2_per_cu_quick_data *quick; } v; + /* The CUs we import using DW_TAG_imported_unit. This is filled in + while reading psymtabs, used to compute the psymtab dependencies, + and then cleared. Then it is filled in again while reading full + symbols, and only deleted when the objfile is destroyed. + + This is also used to work around a difference between the way gold + generates .gdb_index version <=7 and the way gdb does. Arguably this + is a gold bug. For symbols coming from TUs, gold records in the index + the CU that includes the TU instead of the TU itself. This breaks + dw2_lookup_symbol: It assumes that if the index says symbol X lives + in CU/TU Y, then one need only expand Y and a subsequent lookup in Y + will find X. Alas TUs live in their own symtab, so after expanding CU Y + we need to look in TU Z to find X. Fortunately, this is akin to + DW_TAG_imported_unit, so we just use the same mechanism: For + .gdb_index version <=7 this also records the TUs that the CU referred + to. Concurrently with this change gdb was modified to emit version 8 + indices so we only pay a price for gold generated indices. + http://sourceware.org/bugzilla/show_bug.cgi?id=15021. + + This currently needs to be a public member due to how + dwarf2_per_cu_data is allocated and used. Ideally in future things + could be refactored to make this private. Until then please try to + avoid direct access to this member, and instead use the helper + functions above. */ + std::vector *imported_symtabs; + /* Return true of IMPORTED_SYMTABS is empty or not yet allocated. */ bool imported_symtabs_empty () const { @@ -347,32 +373,6 @@ struct dwarf2_per_cu_data delete imported_symtabs; imported_symtabs = nullptr; } - - /* The CUs we import using DW_TAG_imported_unit. This is filled in - while reading psymtabs, used to compute the psymtab dependencies, - and then cleared. Then it is filled in again while reading full - symbols, and only deleted when the objfile is destroyed. - - This is also used to work around a difference between the way gold - generates .gdb_index version <=7 and the way gdb does. Arguably this - is a gold bug. For symbols coming from TUs, gold records in the index - the CU that includes the TU instead of the TU itself. This breaks - dw2_lookup_symbol: It assumes that if the index says symbol X lives - in CU/TU Y, then one need only expand Y and a subsequent lookup in Y - will find X. Alas TUs live in their own symtab, so after expanding CU Y - we need to look in TU Z to find X. Fortunately, this is akin to - DW_TAG_imported_unit, so we just use the same mechanism: For - .gdb_index version <=7 this also records the TUs that the CU referred - to. Concurrently with this change gdb was modified to emit version 8 - indices so we only pay a price for gold generated indices. - http://sourceware.org/bugzilla/show_bug.cgi?id=15021. - - This currently needs to be a public member due to how - dwarf2_per_cu_data is allocated and used. Ideally in future things - could be refactored to make this private. Until then please try to - avoid direct access to this member, and instead use the helper - functions above. */ - std::vector *imported_symtabs; }; /* Entry in the signatured_types hash table. */