From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8lp0LR1li2lP2DMAWB0awg (envelope-from ) for ; Tue, 10 Feb 2026 12:04:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770743069; bh=2C8cbEk8d+jY/W3RuZfMGBg3JDTjou/0l6VUMfeLXds=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=h/RMSbRqOny65V/9KyPrX0yg9fLtdI3IZM/BaOSzghekve1yIlefsM3rOAJ6CzUVt mWA/InCNYBPGGRpXZ7x0KWaLYkfZ9hVwkNwa+aUNxJyLAF3CjHRuo2yB9REGs3Bymw 1dKDDx5gJaFVFbuNiApyco78MAbZ98S/TGhklbZU= Received: by simark.ca (Postfix, from userid 112) id A52B91E0BA; Tue, 10 Feb 2026 12:04:29 -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 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=kMZ7vaGS; dkim-atps=neutral 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 2996A1E08D for ; Tue, 10 Feb 2026 12:04:28 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id C7E004BA2E1B for ; Tue, 10 Feb 2026 17:04:26 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C7E004BA2E1B Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=kMZ7vaGS Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 65D9A4BA2E0D for ; Tue, 10 Feb 2026 17:04:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 65D9A4BA2E0D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 65D9A4BA2E0D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770743040; cv=none; b=pMaDuskibcQmZKzkA9b01nRtt+ooUiBkHpvDTqxmB86bXP/bjfJ1JuSELThoVkQPeSYEt1TF/aSkXt5wDbApwRiqxhQfNuWWJytteuNrCSMeRF2pqgNOgHi6T95J66Q/WGWZKXPqXGedtz/nr5LvRXwZyqqTceF84QIE1IOCD+M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770743040; c=relaxed/simple; bh=2C8cbEk8d+jY/W3RuZfMGBg3JDTjou/0l6VUMfeLXds=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=BluZxyRSQhMdXgD36Y756vmgDnGuFVBlnqD6HhVNgi0ZLFpIWx1jS+4PQbk9L0y5/GyPfwkpgvxVFy4ugZUoUyHQ043W5uPIxZEOuNiWTV23IK+WO+cpT7QUZlTfXbGMHBNUnShCBLMV4s8iTGeYVoNOFz5FVCSDiUnaqlP9cFA= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 65D9A4BA2E0D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770743039; bh=2C8cbEk8d+jY/W3RuZfMGBg3JDTjou/0l6VUMfeLXds=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=kMZ7vaGSeaLT+wX6qJb+yUER1W03nyL8UlWbeevfTYpQyJW+SkhXG7JuNBs9VYzRv 18FMEgy9vvQA3Ok5Yg+pVNimg38kqiy6YmkNmhkUj0gY4KzgnGVyOSmnufAgECZHku ibKR+8c9eHAViOn7dfacw+KkANhqs0zJG7P+43VU= Received: by simark.ca (Postfix) id 00F631E08D; Tue, 10 Feb 2026 12:03:58 -0500 (EST) Message-ID: Date: Tue, 10 Feb 2026 12:03:58 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 8/8] Update .debug_names documentation To: Tom Tromey Cc: gdb-patches@sourceware.org References: <20260126-dw-inline-fixup-pr-symtab-30728-2-v2-0-8ab183d1911c@tromey.com> <20260126-dw-inline-fixup-pr-symtab-30728-2-v2-8-8ab183d1911c@tromey.com> <87zf5gvamk.fsf@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <87zf5gvamk.fsf@tromey.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 2026-02-10 11:14, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > >>> +The @code{DW_IDX_parent} for a C-style enumerator does not point at >>> +the entry for @code{enum} itself, but rather the parent of the type. >>> +The reason for this is that C-style enumerators are injected into the >>> +containing scope, and so their name is not qualified by the >>> +@code{enum}; and furthermore there is no way to distinguish between >>> +C-style enumerators and @code{enum class}-style enumerators in >>> +@samp{.debug_names}. > > Simon> Ok, so IIUC: there is a way to distinguish between C enums and C++ > Simon> enum-class enums in the debug info itself, but not in .debug_names. So > Simon> there is no way just from the index to tell if an enumerator name should > Simon> be visible from the enclosing scope of not. > > Simon> It sounds like another fix I could bring up to the committee, if we can > Simon> find a good solution. > > The gdb fix of changing the parentage seems reasonable. More on the > rationale below. > > Simon> So, is putting enumerators in .debug_names an extension to the standard > Simon> in itself? > > Oh maybe so. > > Simon> I don't really understand the logic of not putting the non-enum-class > Simon> enumerators in the index. > > Indeed but there are many mysteries in DWARF. > > Perhaps omitting enum class enumerators would be ok. It might require > some changes to gdb. I don't plan to work on this, I barely think the > indexes are worthwhile any more. > >>> +Similarly, @code{DW_IDX_parent} is omitted for any linkage name >>> +entries that are written. > > Simon> Is this just an optimization? Because for a linkage name, you don't need > Simon> to know the parent, since there is not need to build the fully qualified > Simon> name? > > gdb could of course ignore the parentage of a linkage name entry. > > But my view is that the name table is there not to tell gdb the DIE > parentage in some abstract way, but instead to indicate the names of > entities. That's because I see the index as an enhancement to lookup > and not as a summary version of the .debug_info. > > This view informs both the enum case and the linkage name case. > > That is, my thought is that the DW_IDX_parent stuff is there to explain > to the debugger how to do a name lookup -- it describes the names, not > the DWARF. > > So, a linkage name doesn't have a parent in this sense, because it is > already a fully-qualified name. And likewise an ordinary enumerator is > hoisted into the outer scope. Ok, so with that in mind, do we even need the DW_IDX_linkage_name attribute? Ah, perhaps yes because the consumer needs to know if it should try to demangle it or not? >>> +A further special case applies to @code{DW_TAG_inlined_subroutine} >>> +entries. An inlined subroutine appearing in a partial unit may be >>> +inlined in all of the outermost compilation units that directly or >>> +indirectly include the partial unit. Therefore, in this case, >>> +@value{GDBN} will emit a separate index entry for the entry, once for >>> +each such containing unit. >>> +@end itemize > > Simon> This question probably relates more to the previous patch, but I don't > Simon> quite understand why this applies to inlined functions but not to other > Simon> entities found in the PU. You'd think that if you have a static > Simon> (file-local) variable defined in a PU, it means that all including CUs > Simon> have this variable defined. So wouldn't you want an entry at that name > Simon> for all these CUs? > > For a variable to be shared in a PU, either it will just be a > declaration and each including CU will have a separate definition that > refers to it; or alternatively every such variable will have the same > address. But in the latter case they are the same variable. You can't have a DW_TAG_variable in a PU that will represent a definition in all the included CUs? For instance, if you have static const char *my_var; inside a C header file included by many C source files. And then, in the DWARF, we "factor out" that DW_TAG_variable into a PU that is "DW_TAG_imported_unit"-imported by many CUs. In that case, wouldn't we have a my_var definition in all CUs? > Inline functions are different. An inline function will have a > DW_TAG_subprogram DIE somewhere (the CU level or appropriate namespace > scope or whatever) that is a marker indicating "this function is inlined > somewhere in this CU". > > If you want to find out where it was inlined, the reader has to scan > that CU looking for DW_TAG_inlined_subroutine. > > In the dwz case, the marker DIE might well be moved into a PU. This > isn't like the variable case because there isn't necessarily an address, > just an DW_AT_inline on the DIE. > > If this DIE is in a PU, then potentially the function has been inlined > somewhere in all including CUs. Ok, so a use case for this would be: the user types "break my_inlined_func", and then you want to find all CUs where my_inlined_func is defined (even through a PU), to find all the inline sites, to put breakpoints on all of them? > > BTW the DWARF approach to inline functions will also hamper incremental > CU expansion (if we ever get there). At the very least when finding an > inline function gdb will have to scan all DIEs in the CUs just in case. That's a bummer, I hope we can find a way around this. Simon