From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id AZlHJMOQuGmykywAWB0awg (envelope-from ) for ; Mon, 16 Mar 2026 19:22:43 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=iZUs4Z7N; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 903191E08C; Mon, 16 Mar 2026 19:22:43 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id B58F31E08C for ; Mon, 16 Mar 2026 19:22:42 -0400 (EDT) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 2C3A64BA543C for ; Mon, 16 Mar 2026 23:22:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2C3A64BA543C Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=iZUs4Z7N Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 5B80D4C515F8 for ; Mon, 16 Mar 2026 23:20:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5B80D4C515F8 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5B80D4C515F8 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773703259; cv=none; b=GuZgy9/ubrNiGtE8u9HfoBdNyiXzDudsRa8qXlA6vdWdf02qkncn32pl5nwDJTc3OnDi4GFW3/BTJipgsUVeBOgHdRrt8AAG/qAFz6od7eopq1GOPqYzqyL1afDLRwY3ElOcZRU3Nq9bZ5WNsGCVvKbSkjYKrbPhlBUkxznGr1A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1773703259; c=relaxed/simple; bh=1OCWVPQgmCGflcQdXzo8wyCV6lmP6NchhjJtzWHHKKM=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=OuM599qmGxu/70K4vtVNqvNrbmXQfjDp5nGJl/i1xFhm3zodNIHAsjEEPZXzKgGUYxmBD28Th4HOqreUdIyifVzLe26BdE7oFAVST8j2uW57fnIQfcIcGkXC+WDg6Oqs4rVzCFaggFCRLTT843HJrUsKN/5JkpL0GmHouesomU0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5B80D4C515F8 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 62GNKpT0238298 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Mar 2026 19:20:56 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 62GNKpT0238298 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1773703256; bh=l/sw64pJm9KPx/yL2QFfXggPSQTvqDXobjIn9sJW43U=; h=From:To:Cc:Subject:Date:In-Reply-To:From; b=iZUs4Z7NYo+u3ER07wsY9kqQ36YosPzS/OdSZ+rivD4cPb6elatmOl91QpPa1fZub fxcGMCjSMvRjzn5f9p5Q0YBTdZf3K3UnxYFO1WBy9wvCFPT3C4u58Ozm8GG6H7Xq6y EOVCJAGNdk809m9lPY+5qGO1rWL5OI2MdZNOZCxJU9yXWTzsnp6BFK4ixBLYyI2YrT iUK9IBMnhtyDMB+4UNhhbtC21HkaHxAqrmDufA4N3jE6+wF/f01VX+Bp/Y8EdAdrzn VrmKhgOvTAPBQMhkAGSZSpj219SXv6mn0JKm9gyiyWqltqUPqT8S2T6A3pFnNcCvKF NhjhVzMeLymIw== Received: by simark.ca (Postfix) id 949DC1E0BC; Mon, 16 Mar 2026 19:20:50 -0400 (EDT) From: simon.marchi@polymtl.ca To: gdb-patches@sourceware.org Cc: Simon Marchi Subject: [PATCH 2/8] gdb/dwarf: move dwo_unit and dwo_file to read.h Date: Mon, 16 Mar 2026 19:19:20 -0400 Message-ID: <20260316232042.368080-3-simon.marchi@polymtl.ca> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260316232042.368080-1-simon.marchi@polymtl.ca> References: <20260316232042.368080-1-simon.marchi@polymtl.ca> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 16 Mar 2026 23:20:51 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org From: Simon Marchi This is to allow index-write.c to see these types, in a later patch. Change-Id: Ia32e0643f95561d3a1bfb67d501c8e20f5682f0e --- gdb/dwarf2/read.c | 125 ---------------------------------------------- gdb/dwarf2/read.h | 125 +++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 124 insertions(+), 126 deletions(-) diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 8b87d58dd9c5..c13ea6c1622f 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -266,86 +266,6 @@ struct loclists_rnglists_header unsigned int offset_entry_count; }; -/* These sections are what may appear in a (real or virtual) DWO file. */ - -struct dwo_sections -{ - struct dwarf2_section_info abbrev; - struct dwarf2_section_info line; - struct dwarf2_section_info loc; - struct dwarf2_section_info loclists; - struct dwarf2_section_info macinfo; - struct dwarf2_section_info macro; - struct dwarf2_section_info rnglists; - struct dwarf2_section_info str; - struct dwarf2_section_info str_offsets; - /* In the case of a virtual DWO file, these two are unused. */ - std::vector infos; - std::vector types; -}; - -/* CUs/TUs in DWP/DWO files. */ - -struct dwo_unit -{ - /* Backlink to the containing struct dwo_file. */ - struct dwo_file *dwo_file = nullptr; - - /* The "id" that distinguishes this CU/TU. - .debug_info calls this "dwo_id", .debug_types calls this "signature". - Since signatures came first, we stick with it for consistency. */ - ULONGEST signature = 0; - - /* The section this CU/TU lives in, in the DWO file. */ - dwarf2_section_info *section = nullptr; - - /* This is set if SECTION is owned by this dwo_unit. */ - dwarf2_section_info_up section_holder; - - /* Same as dwarf2_per_cu::{sect_off,length} but in the DWO section. */ - sect_offset sect_off {}; - unsigned int length = 0; - - /* For types, offset in the type's DIE of the type defined by this TU. */ - cu_offset type_offset_in_tu; -}; - -using dwo_unit_up = std::unique_ptr; - -/* Hash function for dwo_unit objects, based on the signature. */ - -struct dwo_unit_hash -{ - using is_transparent = void; - - std::size_t operator() (ULONGEST signature) const noexcept - { return signature; } - - std::size_t operator() (const dwo_unit_up &unit) const noexcept - { return (*this) (unit->signature); } -}; - -/* Equal function for dwo_unit objects, based on the signature. - - The signature is assumed to be unique within the DWO file. So while object - file CU dwo_id's always have the value zero, that's OK, assuming each object - file DWO file has only one CU, and that's the rule for now. */ - -struct dwo_unit_eq -{ - using is_transparent = void; - - bool operator() (ULONGEST sig, const dwo_unit_up &unit) const noexcept - { return sig == unit->signature; } - - bool operator() (const dwo_unit_up &a, const dwo_unit_up &b) const noexcept - { return (*this) (a->signature, b); } -}; - -/* Set of dwo_unit object, using their signature as identity. */ - -using dwo_unit_set = gdb::unordered_set; - /* include/dwarf2.h defines the DWP section codes. It defines a max value but it doesn't define a min value, which we use for error checking, so provide one. */ @@ -355,51 +275,6 @@ enum dwp_v2_section_ids DW_SECT_MIN = 1 }; -/* Data for one DWO file. - - This includes virtual DWO files (a virtual DWO file is a DWO file as it - appears in a DWP file). DWP files don't really have DWO files per se - - comdat folding of types "loses" the DWO file they came from, and from - a high level view DWP files appear to contain a mass of random types. - However, to maintain consistency with the non-DWP case we pretend DWP - files contain virtual DWO files, and we assign each TU with one virtual - DWO file (generally based on the line and abbrev section offsets - - a heuristic that seems to work in practice). */ - -struct dwo_file -{ - dwo_file () = default; - DISABLE_COPY_AND_ASSIGN (dwo_file); - - /* The DW_AT_GNU_dwo_name or DW_AT_dwo_name attribute. - For virtual DWO files the name is constructed from the section offsets - of abbrev,line,loc,str_offsets so that we combine virtual DWO files - from related CU+TUs. */ - std::string dwo_name; - - /* The DW_AT_comp_dir attribute. */ - const char *comp_dir = nullptr; - - /* The bfd, when the file is open. Otherwise this is NULL. - This is unused(NULL) for virtual DWO files where we use dwp_file.dbfd. */ - gdb_bfd_ref_ptr dbfd; - - /* The sections that make up this DWO file. - Remember that for virtual DWO files in DWP V2 or DWP V5, these are virtual - sections (for lack of a better name). */ - struct dwo_sections sections {}; - - /* The CUs in the file. - - Multiple CUs per DWO are supported as an extension to handle LLVM's Link - Time Optimization output (where multiple source files may be compiled into - a single object/dwo pair). */ - dwo_unit_set cus; - - /* Table of TUs in the file. */ - dwo_unit_set tus; -}; - /* See dwarf2/read.h. */ std::size_t diff --git a/gdb/dwarf2/read.h b/gdb/dwarf2/read.h index 86f97e7ccf4a..5a46786e4f3f 100644 --- a/gdb/dwarf2/read.h +++ b/gdb/dwarf2/read.h @@ -489,7 +489,130 @@ using signatured_type_set = gdb::unordered_set; -struct dwo_file; +/* CUs/TUs in DWP/DWO files. */ + +struct dwo_unit +{ + /* Backlink to the containing struct dwo_file. */ + struct dwo_file *dwo_file = nullptr; + + /* The "id" that distinguishes this CU/TU. + .debug_info calls this "dwo_id", .debug_types calls this "signature". + Since signatures came first, we stick with it for consistency. */ + ULONGEST signature = 0; + + /* The section this CU/TU lives in, in the DWO file. */ + dwarf2_section_info *section = nullptr; + + /* This is set if SECTION is owned by this dwo_unit. */ + dwarf2_section_info_up section_holder; + + /* Same as dwarf2_per_cu::{sect_off,length} but in the DWO section. */ + sect_offset sect_off {}; + unsigned int length = 0; + + /* For types, offset in the type's DIE of the type defined by this TU. */ + cu_offset type_offset_in_tu; +}; + +using dwo_unit_up = std::unique_ptr; + +/* These sections are what may appear in a (real or virtual) DWO file. */ + +struct dwo_sections +{ + struct dwarf2_section_info abbrev; + struct dwarf2_section_info line; + struct dwarf2_section_info loc; + struct dwarf2_section_info loclists; + struct dwarf2_section_info macinfo; + struct dwarf2_section_info macro; + struct dwarf2_section_info rnglists; + struct dwarf2_section_info str; + struct dwarf2_section_info str_offsets; + /* In the case of a virtual DWO file, these two are unused. */ + std::vector infos; + std::vector types; +}; + +/* Hash function for dwo_unit objects, based on the signature. */ + +struct dwo_unit_hash +{ + using is_transparent = void; + + std::size_t operator() (ULONGEST signature) const noexcept + { return signature; } + + std::size_t operator() (const dwo_unit_up &unit) const noexcept + { return (*this) (unit->signature); } +}; + +/* Equal function for dwo_unit objects, based on the signature. + + The signature is assumed to be unique within the DWO file. So while object + file CU dwo_id's always have the value zero, that's OK, assuming each object + file DWO file has only one CU, and that's the rule for now. */ + +struct dwo_unit_eq +{ + using is_transparent = void; + + bool operator() (ULONGEST sig, const dwo_unit_up &unit) const noexcept + { return sig == unit->signature; } + + bool operator() (const dwo_unit_up &a, const dwo_unit_up &b) const noexcept + { return (*this) (a->signature, b); } +}; + +/* Set of dwo_unit object, using their signature as identity. */ + +using dwo_unit_set = gdb::unordered_set; + +/* Data for one DWO file. + + This includes virtual DWO files (a virtual DWO file is a DWO file as it + appears in a DWP file). DWP files don't really have DWO files per se - + comdat folding of types "loses" the DWO file they came from, and from + a high level view DWP files appear to contain a mass of random types. + However, to maintain consistency with the non-DWP case we pretend DWP + files contain virtual DWO files, and we assign each TU with one virtual + DWO file (generally based on the line and abbrev section offsets - + a heuristic that seems to work in practice). */ + +struct dwo_file +{ + dwo_file () = default; + DISABLE_COPY_AND_ASSIGN (dwo_file); + + /* The DW_AT_GNU_dwo_name or DW_AT_dwo_name attribute. + For virtual DWO files the name is constructed from the section offsets + of abbrev,line,loc,str_offsets so that we combine virtual DWO files + from related CU+TUs. */ + std::string dwo_name; + + /* The DW_AT_comp_dir attribute. */ + const char *comp_dir = nullptr; + + /* The bfd, when the file is open. Otherwise this is NULL. + This is unused(NULL) for virtual DWO files where we use dwp_file.dbfd. */ + gdb_bfd_ref_ptr dbfd; + + /* The sections that make up this DWO file. + Remember that for virtual DWO files in DWP V2 or DWP V5, these are virtual + sections (for lack of a better name). */ + struct dwo_sections sections {}; + + /* The CUs in the file. + + Multiple CUs per DWO are supported as an extension to handle LLVM's Link + Time Optimization output (where multiple source files may be compiled into + a single object/dwo pair). */ + dwo_unit_set cus; + + /* Table of TUs in the file. */ + dwo_unit_set tus; +}; using dwo_file_up = std::unique_ptr; -- 2.53.0