From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id XNU5EyJtnWkXWQgAWB0awg (envelope-from ) for ; Tue, 24 Feb 2026 04:19:30 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=zdT2UieY; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=ztU4DXq3; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=zdT2UieY; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=ztU4DXq3; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 39C401E089; Tue, 24 Feb 2026 04:19:30 -0500 (EST) 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 145541E089 for ; Tue, 24 Feb 2026 04:19:29 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 7F4264B9DB7E for ; Tue, 24 Feb 2026 09:19:27 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7F4264B9DB7E Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=zdT2UieY; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=ztU4DXq3; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=zdT2UieY; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=ztU4DXq3 Received: from smtp-out1.suse.de (smtp-out1.suse.de [IPv6:2a07:de40:b251:101:10:150:64:1]) by sourceware.org (Postfix) with ESMTPS id 759C64BA23F9 for ; Tue, 24 Feb 2026 09:18:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 759C64BA23F9 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 759C64BA23F9 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:1 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1771924739; cv=none; b=dKNZ3CkhXjw2836gN+QHpNrxQXIxFh9epNbVUipoBZSi9S1ZxqWEJ7P+wJdEsOQD4fyfhj+8jnt12oUqI6cTymqjiD5yUFXYzEvWl/TbVuKHx63w4plTmHBzLI0Ki6e+2vs0M8+yNX/Cvx+NHJ2S1G7eCpLKoTeSqWPTez1PXF8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1771924739; c=relaxed/simple; bh=yfhFDQ7tooZ1VfR7LLDdlu1njB+e/iiwICMFjoXgUZI=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:From:Subject:To; b=rbxzoJOwDZylUHSZF1oI7AlIt+KKunoOnkKLJX8bm9HiL1l68qpENjOng8XQy2PBlcSTHIm6qsxr9U8H4s4UBQghPE/rTdtmn+6lOtFWPvpk2Sp2+bNZL8MeLMrPKclBf/YD/QAykq3C7xHOKYkxm+xnIgP+7QmIYgMc7l44OG8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 759C64BA23F9 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 62CE33F136; Tue, 24 Feb 2026 09:18:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1771924738; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V8EIKDpIuSTGwVML4oFPTgb2p1E5QC0klkzXqwkpRzE=; b=zdT2UieYpy5meipGngADpxX+kf7JdhlPW+j6XUP2RZ6ecjXm4rDi27JIuKMGgscNAD1Eoe sFVpkud4LQRf3CwEPEdM4X6eL7QFghenDg3FDCXM/hqABnOAI0iVcqen4YK2oS6NQHZkT0 Ann5Rry0pZugV3Iz/kJwojtATr4dsB8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1771924738; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V8EIKDpIuSTGwVML4oFPTgb2p1E5QC0klkzXqwkpRzE=; b=ztU4DXq3Ay77vS4yFMxKUSvGpQWlzZsXA6oh0CFGyDFZKVomJROiHUiynJwggbOMUXV3ef R10piQW7rfBZTeBQ== Authentication-Results: smtp-out1.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1771924738; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V8EIKDpIuSTGwVML4oFPTgb2p1E5QC0klkzXqwkpRzE=; b=zdT2UieYpy5meipGngADpxX+kf7JdhlPW+j6XUP2RZ6ecjXm4rDi27JIuKMGgscNAD1Eoe sFVpkud4LQRf3CwEPEdM4X6eL7QFghenDg3FDCXM/hqABnOAI0iVcqen4YK2oS6NQHZkT0 Ann5Rry0pZugV3Iz/kJwojtATr4dsB8= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1771924738; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=V8EIKDpIuSTGwVML4oFPTgb2p1E5QC0klkzXqwkpRzE=; b=ztU4DXq3Ay77vS4yFMxKUSvGpQWlzZsXA6oh0CFGyDFZKVomJROiHUiynJwggbOMUXV3ef R10piQW7rfBZTeBQ== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 447173EA68; Tue, 24 Feb 2026 09:18:58 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id yAqBDwJtnWkldQAAD6G6ig (envelope-from ); Tue, 24 Feb 2026 09:18:58 +0000 Message-ID: Date: Tue, 24 Feb 2026 10:18:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Tom de Vries Subject: Re: [PATCH v4 5/8] Remove C++ special case from process_imported_unit_die To: Tom Tromey , gdb-patches@sourceware.org References: <20260223-dw-inline-fixup-pr-symtab-30728-2-v4-0-bf923dc5fb19@tromey.com> <20260223-dw-inline-fixup-pr-symtab-30728-2-v4-5-bf923dc5fb19@tromey.com> Content-Language: en-US In-Reply-To: <20260223-dw-inline-fixup-pr-symtab-30728-2-v4-5-bf923dc5fb19@tromey.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spamd-Result: default: False [-4.30 / 50.00]; BAYES_HAM(-3.00)[100.00%]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; RCPT_COUNT_TWO(0.00)[2]; FUZZY_RATELIMITED(0.00)[rspamd.com]; MIME_TRACE(0.00)[0:+]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[imap1.dmz-prg2.suse.org:helo,suse.de:mid] 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 On 2/24/26 2:16 AM, Tom Tromey wrote: > 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. Hi Tom, this is the type of debuginfo generated by gcc for lto. To briefly reiterate: - at an early stage of compilation, type info is generated for each compilation unit, resulting in a CU with only types, so no addresses. - then lto optimization happens, resulting in one blob of code per optimization unit (an lto partition), and debug info is generated for that blob (a CU with name ""). - the artificial CU imports the CUs in the partition. Importing a CU feels strange to me, but the DWARF standard (quoting v4) seems to allow it: ... 3.1.2 Imported Unit Entries The place where a normal or partial unit is imported is represented by a debugging information entry with the tag DW_TAG_imported_unit. An imported unit entry contains a DW_AT_import attribute whose value is a reference to the normal or partial compilation unit whose declarations logically belong at the place of the imported unit entry. An imported unit entry does not necessarily correspond to any entity or construct in the source program. It is merely “glue” used to relate a partial unit, or a compilation unit used as a partial unit, to a place in some other compilation unit. ... > First, it is specific to C++. I don't see any real reason that this > should be the case. I implemented the optimization for cases where I could prove it was safe. For C++, we have a global namespace so importing the types from a CU once or twice into the global namespace should have the same effect. For C, each CU has it's own namespace, so each import is significant. The DWARF standard refers to this difference here: ... C Example The C++ example in this Section might appear to be equally valid as a C example. However, it is prudent to include a DW_TAG_imported_unit in the primary unit (see Figure 84) with an DW_AT_import attribute that refers to the proper unit in the section group. The C rules for consistency of global (file scope) symbols across compilations are less strict than for C++; inclusion of the import unit attribute assures that the declarations of the proper section group are considered before declarations from other compilations. ... It could be that with the current implementation, this difference is no longer relevant, I'm not sure. > 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. > I see. > Instead, because (1) this is weird and rare DWARF anyway, and (2) this > is just a performance optimization, I propose removing this. I agree removing it is the right thing to do. I also feels weird to me, though the DWARF standard explicitly allows it. But from the perspective of a linux distro using gcc and lto for package compilation, it's the opposite of rare. Anyway, I've filed a PR to reimplement this in some form or another ( https://sourceware.org/bugzilla/show_bug.cgi?id=33922 ). Thanks, - Tom > --- > gdb/dwarf2/read.c | 9 --------- > 1 file changed, 9 deletions(-) > > diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c > index 5917e697aad..e48745d7969 100644 > --- a/gdb/dwarf2/read.c > +++ b/gdb/dwarf2/read.c > @@ -4890,15 +4890,6 @@ process_imported_unit_die (struct die_info *die, struct dwarf2_cu *cu) > dwarf2_per_cu *per_cu > = dwarf2_find_containing_unit ({ §ion, 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 ()); >