From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CZHwNJNZi2lxyDMAWB0awg (envelope-from ) for ; Tue, 10 Feb 2026 11:15:15 -0500 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (768-bit key; unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=qPkzxvgH; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D2FB61E08D; Tue, 10 Feb 2026 11:15:15 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_BL_SPAMCOP_NET, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no 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 E34D21E08D for ; Tue, 10 Feb 2026 11:15:14 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 930034BA2E24 for ; Tue, 10 Feb 2026 16:15:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 930034BA2E24 Authentication-Results: sourceware.org; dkim=fail reason="signature verification failed" (768-bit key, unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=qPkzxvgH Received: from omta38.uswest2.a.cloudfilter.net (omta38.uswest2.a.cloudfilter.net [35.89.44.37]) by sourceware.org (Postfix) with ESMTPS id 4B00B4BA2E09 for ; Tue, 10 Feb 2026 16:14:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4B00B4BA2E09 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 4B00B4BA2E09 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=35.89.44.37 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770740086; cv=none; b=Lsh8PacAuGWhABDQ+T/mzypbQwiMvi16a8UhOPkGVJ02c+QP3qx3fcVhODXnV+cr2BZG8/W/Jc2g/nB7rq5YmhIDb8aKg/nVH1rEgZOxXQ5FRi5UupzBlYi+fGnvaPDoNRyZsTkv6GyEkd56W1SADMfFvOO5a24YDIFEFVnkfgk= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770740086; c=relaxed/simple; bh=6PouqZe7bJZWoeZB2h8vn02/W19+gHiAv4ZzfuyCAnQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=wfVBr+rRIlGh4WL8d9rnRjnCj79TGObTANbsTq5EvKyRKt5qN44ImWMPyfiNAb3Dqfl2lhxKf/3axsHorSD4Vzfe/8o2wFTXpeWyPYg6SJsuzgGFg/PnsRAatGYLK6X75tnz6VN6xvHkj9nksV22PxNcSJ1n+hyK2q2ZFFL6z4k= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4B00B4BA2E09 Received: from eig-obgw-6003b.ext.cloudfilter.net ([10.0.30.175]) by cmsmtp with ESMTPS id pnSVv8UvZipkCpqNxvc5c0; Tue, 10 Feb 2026 16:14:45 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id pqNwvpXafhoT4pqNxvx0JC; Tue, 10 Feb 2026 16:14:45 +0000 X-Authority-Analysis: v=2.4 cv=XZyJzJ55 c=1 sm=1 tr=0 ts=698b5975 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=HzLeVaNsDn8A:10 a=ItBw4LHWJt0A:10 a=dzWzf_mpAAAA:8 a=HZ4BJ2-rUIZ5HoBQ8gYA:9 a=b4DR9a7p2ZdsqdHBznES:22 a=DCx65vhANUyCzuf5D8fC:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=iv2Gz37ci7vyNZmC5vksvEfuHHDy98blno0aXLkdxeA=; b=qPkzxvgHa/DF+WrxFEs6b1Inim zwKB7vR3HLGsHxTDUijvf3jz2VOheSyi5q/aUIpXb9nNkkfUI2F3ZtKrqII7nosuvK9j90DFfBSA9 A3UmpR4c1H1TUoVSc24+pqFUW; Received: from 97-118-49-200.hlrn.qwest.net ([97.118.49.200]:49950 helo=prentzel) by box5379.bluehost.com with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vpqNw-00000002Mq1-2KOy; Tue, 10 Feb 2026 09:14:44 -0700 From: Tom Tromey To: Simon Marchi Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH v2 8/8] Update .debug_names documentation In-Reply-To: (Simon Marchi's message of "Mon, 9 Feb 2026 23:26:57 -0500") 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> X-Attribution: Tom Date: Tue, 10 Feb 2026 09:14:43 -0700 Message-ID: <87zf5gvamk.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.118.49.200 X-Source-L: No X-Exim-ID: 1vpqNw-00000002Mq1-2KOy X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-118-49-200.hlrn.qwest.net (prentzel) [97.118.49.200]:49950 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfK7Q2+9SEv/uHKRLVB87929VeH8qyNDwzTy7cltRMg+ZDwmx78oh1WY2WeqBIkpYAIQ5anx8LzK+xI/pmO/z7zIHPlMj6OBqod69srQr44qDarcv1RXa FJ92z73EMXyJDNYNLGJfW+VCf0hghq1yH3TJECc+IjkdWeq4NUZB/bfqcan3qTuVdccFcm4VKWJGD4X/+tBJMmzV7Ah9gNSzG2I= 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 >>>>> "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. >> +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. 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. 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. Tom