From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id cCMWN0OrimnNyjIAWB0awg (envelope-from ) for ; Mon, 09 Feb 2026 22:51:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770695491; bh=o3nV4X6yi7MedLOkmG6FLU+0enErqFb6+lKfn4oghmk=; h=Date:Subject:To:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=kUQqHXo9TWcZmTRNBprrUyC2r+2dT/aMtkq+VjullO14a+0Nd1GEqu2KjKJAI6DsO sWu77KTc3xFfBti3uRHPb/Cu2X6xrfKOb47+VaVvaRcqIoPBKy86cvM8lYyaNv0OlO LPHg6XU51ka0AnKcoQDSgldj80D+ivrnhEg9bh5g= Received: by simark.ca (Postfix, from userid 112) id B3B251E0BA; Mon, 09 Feb 2026 22:51:31 -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=vzCx/fj9; 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 CEB571E089 for ; Mon, 09 Feb 2026 22:51:30 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 2F49D4BBC0B5 for ; Tue, 10 Feb 2026 03:51:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2F49D4BBC0B5 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=vzCx/fj9 Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 1A46C4BB58F2 for ; Tue, 10 Feb 2026 03:51:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A46C4BB58F2 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 1A46C4BB58F2 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=1770695463; cv=none; b=Zvtk6X00cyLQ8UHw6TuLOSK5u8MfEH9Y1YaUfeByoHsI3Ilwwpj51YgyUylV03epQtNokCGX33kWjQcowhMISDmodXJSqtKlJMWBCodJFKvS7OpBa3UfLCrcePzGkVC7FBoWHio5H9rm5BrkhCNvhZCB8RmEY9uHL/Jtoi8J65w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770695463; c=relaxed/simple; bh=o3nV4X6yi7MedLOkmG6FLU+0enErqFb6+lKfn4oghmk=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=IBfekUcQvjT+I5pN+7KxqMGXCp5WI5N6FRfvLvY4n9uIpCouEc5+rCcGR+x46fhN+9V2qXYT5/cg9RKhcH9tfXlyc2n6Z38PrsyTbvz3e/Zgf8ANAzZ1xjwJzrBU4X1FMHvJdeq8ny+U6ieebcHG4Sqz1MdY2sqC92YqBuCdN98= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1A46C4BB58F2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1770695461; bh=o3nV4X6yi7MedLOkmG6FLU+0enErqFb6+lKfn4oghmk=; h=Date:Subject:To:References:From:In-Reply-To:From; b=vzCx/fj9B7cJo3RZqAxU2yxAfyPYSCZBZIVwbTEtyZ8CrsNgn8MFB4UAWdsA39Jgz yaR2C9kQjcAJc2Vh1josr8UZDgTYkI5aMIGZo0iZkJS2MQdrs54VjZD2uX7+HC0Azt cALh+W1yejHKLUilzEH0n9xzLK8c+QD8dj/LZwPs= Received: by simark.ca (Postfix) id 9A1B71E089; Mon, 09 Feb 2026 22:51:01 -0500 (EST) Message-ID: <6136d297-6822-4a97-bb68-a6d3322a15e6@simark.ca> Date: Mon, 9 Feb 2026 22:51:00 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 7/8] Handle inline functions with dwz 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-7-8ab183d1911c@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <20260126-dw-inline-fixup-pr-symtab-30728-2-v2-7-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: > Currently, gdb does not properly handle inline functions when dwz is > used. This can be seen by running gdb.cp/breakpoint-locs.exp with the > cc-with-dwz target board. > > The problem here is that inline functions need special handling in the > dwz case. > > First, recall that a DWARF partial unit cannot, in general, be read in > isolation, as it may not have a language. To handle this, gdb defers > scanning partial units directly, and instead scans them in the context > of some including CU. > > Entries coming from the PU are attributed to this reading CU. If > multiple CUs import a PU, gdb has the reader threads race to see which > one does the actual reading. > > However, if an inline function is moved into a partial unit, then that > means it has potentially been inlined somewhere in every including CU. > > Thus, when linespec searches for this function, each such including CU > should be expanded. But because gdb only attributed the function's > index entry to one CU, only that particular one is expanded. > > This patch fixes this bug. All inclusions of a PU are recorded. > Entries coming from a PU are attributed to that PU. For most entries > coming from the PU, a single "canonical" outer CU is chosen to expand. > However, when an inline function is found, all such CUs are expanded. > > A change was also needed to the index writer to handle this case. > There, entries coming from a PU should note the correct including CU. > This must be done because, with .debug_names or .gdb_index, gdb does > not have information about unit imports. Handling inline functions > here means writing out a separate entry for each outermost CU that > includes the function's PU. > > I did consider changing the cooked indexer to create an internal table > more similar to what would be created by the .debug_names (e.g.) > reader: that is, multiple entries for each inline function. However, > this seemed more expensive at read time, and a main goal of the cooked > indexer is to be fast. The description make sense to me. I think the dwz-ing of the DWARF should be seen as an internal implementation detail to factor common things, but from the "outside", it's the real CUs/TUs that count. Semantically, we must do "as-if" there was no factoring out. Simon