From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 03CwIleUi2lhJjQAWB0awg (envelope-from ) for ; Tue, 10 Feb 2026 15:25:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770755159; bh=meL7ba2LSfqU2qe6FRFvdDDHEcuDB3T746af4JtUS54=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=F2zGZCWWhZWZnDjg/rOJYWMx0bBgjOUt/tG6oGDIC+ry9nERRAKQFpGjSRYsYYF59 ctLzElqTO8DtQ61Xw/Kft0ooKuOBhN5Av440qlyZ5YqVQ5v7up9H2m05uqXvk7ObBa esSFIsoIJAU/r1WiOFs+JXWrYE5Xn7VL/b7XbO0U= Received: by simark.ca (Postfix, from userid 112) id 7035A1E0BA; Tue, 10 Feb 2026 15:25:59 -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=dAVtGMB5; 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 73B5A1E08D for ; Tue, 10 Feb 2026 15:25:58 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id E881E4BA23D1 for ; Tue, 10 Feb 2026 20:25:57 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E881E4BA23D1 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=dAVtGMB5 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 9EC164BA2E11 for ; Tue, 10 Feb 2026 20:25:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9EC164BA2E11 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 9EC164BA2E11 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=1770755133; cv=none; b=giLyF/ZdUYAzUTo25Se5Jv86Nv21hQUtSiiS3JIpyTHudWbmtXSylN2Zy+lp/ozxZ37l9l862yjRCSevyhNkuzu4MyKsTtOmQYfg7EIQkwLmTXamXgs4Awj6sWioTWbBE4fNn94BTZPWeIVG2BRYrVdH6fcgZnj0DwPz2AtEXrE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770755133; c=relaxed/simple; bh=meL7ba2LSfqU2qe6FRFvdDDHEcuDB3T746af4JtUS54=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=rmvTHfTpo1O/5yo1gm/ekgwQg9cuNcborNBM2eNuw6up6inPQSaMd8orHRTlQAaNxeXU5SmAU4qxfExOcbf3BwkpO0f8BfevudK+yAxWdpCzx5NmDv7Vi0J43GOzDRc7RZi4EjAA6SoypJdiFRS9IIHeZwfD0a0NjRzwaTkIrUY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9EC164BA2E11 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770755132; bh=meL7ba2LSfqU2qe6FRFvdDDHEcuDB3T746af4JtUS54=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=dAVtGMB5drc8+OefB2MQ1WGgWz4SeWz7U79b9iWBGLsLKZtTNz2kKCRCgaGplD0oz uF0BiX7ajOYfPhyyw1Lpcku/k1ZsufwXCSZMwcAk7rrnyZYfKnyxgsxZqEonWtudsv AhLI2DGRbgdZoCFFs2iZVt04XNNXrG1YBld9Qxwc= Received: by simark.ca (Postfix) id 506061E08D; Tue, 10 Feb 2026 15:25:32 -0500 (EST) Message-ID: <72ab46ea-9db9-4af7-9dc0-9165f2853013@simark.ca> Date: Tue, 10 Feb 2026 15:25:31 -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> <87ikc41im3.fsf@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <87ikc41im3.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 14:52, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > >>> 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. > > Simon> You can't have a DW_TAG_variable in a PU that will represent a definition > Simon> in all the included CUs? For instance, if you have > > Simon> static const char *my_var; > > Simon> inside a C header file included by many C source files. And then, in > Simon> the DWARF, we "factor out" that DW_TAG_variable into a PU that is > Simon> "DW_TAG_imported_unit"-imported by many CUs. In that case, wouldn't we > Simon> have a my_var definition in all CUs? > > This approach would make a different variable in each CU. They would > all share a name but have different addresses. So while it's possible > to share some of this in a PU (like, the name, type, and source > location), each CU would still end up with a separate DIE describing the > address. Ah, thanks. > > Simon> Ok, so a use case for this would be: the user types "break > Simon> my_inlined_func", and then you want to find all CUs where > Simon> my_inlined_func is defined (even through a PU), to find all the inline > Simon> sites, to put breakpoints on all of them? > > Yes. That's the failure addressed by the series. Perfect, thanks. >>> 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. > > Simon> That's a bummer, I hope we can find a way around this. > > Since the reader pre-loads all the DIEs I am thinking it probably won't > be super expensive to also iterate over them. Or alternatively we could > have the DIE-loading process notice all the spots where an inlined > function is seen. I was actually wondering if we could avoid pre-loading all the DIEs from the start. But if we need to to a full scan for something like this... IWBN to measure how long it takes to just read the DIEs, and then to iterate over all DIEs doing nothing. Then we'll know if we need to care about that part or not. Simon