Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom Tromey <tom@tromey.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [PATCH v3 5/8] Remove C++ special case from process_imported_unit_die
Date: Fri, 20 Feb 2026 13:42:25 -0700	[thread overview]
Message-ID: <20260220-dw-inline-fixup-pr-symtab-30728-2-v3-5-98ae8ab28fab@tromey.com> (raw)
In-Reply-To: <20260220-dw-inline-fixup-pr-symtab-30728-2-v3-0-98ae8ab28fab@tromey.com>

process_imported_unit_die has a special case for C++, added as a
performance improvement.

While I somewhat agree with the general idea of this snippet --
importing a compilation unit seems like a strange thing to do, given
that partial units exist -- I think there are two issues with it.

First, it is specific to C++.  I don't see any real reason that this
should be the case.

Second, it does not have a corresponding bit of code in the indexer.
This means that the cooked index's view of the DWARF differs from the
full reader's view here.  This causes regressions in this series,
because the indexer assumes that reading a CU will cause all the
imported CUs to be read as a side effect -- but that does not happen
here.

I think fixing this in the indexer is not trivial.  The reason for
this is that the indexer works in parallel, and once a reader has
acquired the "scan" bit for a CU, it is obligated to read it.
However, in this case this would require making a new cooked indexer.

Instead, because (1) this is weird and rare DWARF anyway, and (2) this
is just a performance optimization, I propose removing this.
---
 gdb/dwarf2/read.c | 9 ---------
 1 file changed, 9 deletions(-)

diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c
index 184ffe1c213..141a6ea066f 100644
--- a/gdb/dwarf2/read.c
+++ b/gdb/dwarf2/read.c
@@ -4886,15 +4886,6 @@ process_imported_unit_die (struct die_info *die, struct dwarf2_cu *cu)
       dwarf2_per_cu *per_cu
 	= dwarf2_find_containing_unit ({ &section, sect_off }, per_objfile);
 
-      /* We're importing a C++ compilation unit with tag DW_TAG_compile_unit
-	 into another compilation unit, at root level.  Regard this as a hint,
-	 and ignore it.  This is a best effort, it only works if unit_type and
-	 lang are already set.  */
-      if (die->parent && die->parent->parent == NULL
-	  && per_cu->unit_type (false) == DW_UT_compile
-	  && per_cu->lang (false) == language_cplus)
-	return;
-
       /* If necessary, add it to the queue and load its DIEs.  */
       if (maybe_queue_comp_unit (cu, per_cu, per_objfile))
 	load_full_comp_unit (per_cu, per_objfile, false, cu->lang ());

-- 
2.49.0


  parent reply	other threads:[~2026-02-20 20:45 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-20 20:42 [PATCH v3 0/8] Correctly handle inline functions with dwz Tom Tromey
2026-02-20 20:42 ` [PATCH v3 1/8] Don't call add_dependence from index_imported_unit Tom Tromey
2026-02-20 20:42 ` [PATCH v3 2/8] Skip partial units in process_psymtab_comp_unit Tom Tromey
2026-02-20 20:42 ` [PATCH v3 3/8] Don't consider DW_TAG_inlined_subroutine as interesting Tom Tromey
2026-02-20 20:42 ` [PATCH v3 4/8] Combine two cases in cooked_index_functions::search Tom Tromey
2026-02-20 20:42 ` Tom Tromey [this message]
2026-02-20 20:42 ` [PATCH v3 6/8] Have iterate_over_one_compunit_symtab search included symtabs Tom Tromey
2026-02-20 20:42 ` [PATCH v3 7/8] Handle inline functions with dwz Tom Tromey
2026-02-20 20:42 ` [PATCH v3 8/8] Update .debug_names documentation Tom Tromey
2026-02-23 13:30 ` [PATCH v3 0/8] Correctly handle inline functions with dwz Sam James
2026-02-23 13:32   ` Sam James
2026-02-23 13:34   ` Simon Marchi
2026-02-23 13:48     ` Sam James
2026-02-23 22:31   ` Tom Tromey

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260220-dw-inline-fixup-pr-symtab-30728-2-v3-5-98ae8ab28fab@tromey.com \
    --to=tom@tromey.com \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox