From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id tX76DLKzimnI1jIAWB0awg (envelope-from ) for ; Mon, 09 Feb 2026 23:27:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770697650; bh=7VeOjEkoscJ6LETViBQuXEp/eXwzroRnrfNaxwybHTM=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=VfI06r7C/Qh9R8Kko80Kw9KDL61WE3Fwtav3DPgFHk9rdMwVQV0u4YVz5yNXhEt8l fep4SsgZylkoY2J7IUO77NcRr0Sz9ERIcHqfjOCLDnscqUE0aPmiZJbfzeL+D5ArGq cSH1qYKyXEU50KwuMupi11zbzxgB0BNzsOPWdk4k= Received: by simark.ca (Postfix, from userid 112) id 182031E0BA; Mon, 09 Feb 2026 23:27: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 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=E4NLt0c1; 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 52F8F1E089 for ; Mon, 09 Feb 2026 23:27:25 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id B44644BBCD9B for ; Tue, 10 Feb 2026 04:27:24 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B44644BBCD9B 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=E4NLt0c1 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id EFD3A4BA23E6 for ; Tue, 10 Feb 2026 04:26:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EFD3A4BA23E6 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 EFD3A4BA23E6 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=1770697619; cv=none; b=T6Yhhnko3CrF/7N2ss2gwCz8cnUbW90v0EH2dVqGpiT8uURifZ5I0QUz8ELQj0KXMn0tcVTvQ3pXmu9t7FBVuS/ulfOE8/ijFeLsHau619c1pCGL+Csa1slPyMvRKNUCH7AyQkn6k2iox57lNaih4AD5iYqJxFBq3G2aXdwzsiM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770697619; c=relaxed/simple; bh=7VeOjEkoscJ6LETViBQuXEp/eXwzroRnrfNaxwybHTM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=X+MSUf6pN6XP7euATu3jnEXj8uGBPxQpoQSAklSmQetIklcAYEj2/K8zx7mkHwJ1pQBno4Q9GyWLJRNfgJG6GX3BOMutxkDI4/cmHAyaQKP8WpESi9Mi/qcI+D0k9W12Rd7y6BtsCogZ4nyIs4QmgWGN3l5Kre1CF+V8T4e1IXQ= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EFD3A4BA23E6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770697618; bh=7VeOjEkoscJ6LETViBQuXEp/eXwzroRnrfNaxwybHTM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=E4NLt0c14l/CvlbxnXahkFnTxO6sXW7j5dZX7OsGNE5qIpjEOnOKFHJvV9QpUcsdH QJOW2V8voB37sI6vOYiEOXWCuNg6U0s+zSKbO7w/td1qdFK9wSoMrZp04p1sGeNphn MNFdvfX1rIRAyYx4qZcxXG18gF+B8ePqZzvGBd+E= Received: by simark.ca (Postfix) id 18FCF1E089; Mon, 09 Feb 2026 23:26:58 -0500 (EST) Message-ID: Date: Mon, 9 Feb 2026 23:26:57 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 8/8] Update .debug_names documentation To: Tom Tromey , 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> Content-Language: en-US From: Simon Marchi In-Reply-To: <20260126-dw-inline-fixup-pr-symtab-30728-2-v2-8-8ab183d1911c@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-01-26 16:33, Tom Tromey wrote: > This updates the .debug_names documentation to explain some DWARF > issues that we've handled in gdb. > > This list still isn't exhaustive. I think there are some situations > where gdb may examine a declaration (which DWARF says not to do), but > I didn't document this as I don't recall the details. > --- > gdb/doc/gdb.texinfo | 37 +++++++++++++++++++++++++++++++++++++ > 1 file changed, 37 insertions(+) > > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index 80f49e21b7e..1b3813286e6 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -23297,6 +23297,43 @@ source name. > > @end table > > +@value{GDBN} also has some special handling for cases not considered > +in the DWARF specification. > + > +@itemize @bullet > +@item > +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}. Ok, so IIUC: there is a way to distinguish between C enums and C++ enum-class enums in the debug info itself, but not in .debug_names. So there is no way just from the index to tell if an enumerator name should be visible from the enclosing scope of not. It sounds like another fix I could bring up to the committee, if we can find a good solution. Note: I found this proposal that suggested adding enumerators to the index, and it was rejected, "Size impact would be too great.". https://dwarfstd.org/issues/230224.1.html So, is putting enumerators in .debug_names an extension to the standard in itself? I don't really understand the logic of not putting the non-enum-class enumerators in the index. If you have: enum Foo { Foo_Bar = 12, }; then you want "print Foo_Bar" to work, which requires "Foo_bar" to be find-able. > + > +@item > +Similarly, @code{DW_IDX_parent} is omitted for any linkage name > +entries that are written. Is this just an optimization? Because for a linkage name, you don't need to know the parent, since there is not need to build the fully qualified name? I don't know if this is actually an extension or not. Is it mandantory to include a DW_IDX_parent (if there is an indexed parent), according to the spec? As usual, DWARF is not clear about that. I suppose that this works in conjunction with DW_IDX_GNU_linkage_name? It is currently being proposed for standardization here: https://dwarfstd.org/issues/251122.1.html If accepted, I could propose a change that says clearly "for entries with DW_IDX_linkage_name, a DW_IDX_parent is not required". > + > +@item > +Definitions in partial units are handled differently. These most > +typically are seen in the output of @code{dwz}. > + > +In general, a DWARF partial unit cannot be read in isolation, but only > +by reading it in the context of some other unit that references it via > +@code{DW_TAG_imported_unit}. > + > +Therefore, an ordinary definition in a partial unit is attributed to > +one of the outermost containing units. This is done by referencing > +this containing CU in the @code{DW_IDX_compile_unit} attribute. It's not explicitly said in the spec, but this is how I understand it is expected to work. There is no way to for an index entry to reference a PU anyway. > +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 This question probably relates more to the previous patch, but I don't quite understand why this applies to inlined functions but not to other entities found in the PU. You'd think that if you have a static (file-local) variable defined in a PU, it means that all including CUs have this variable defined. So wouldn't you want an entry at that name for all these CUs? Simon