From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id GRDMFfBdqWpFmg4AWB0awg (envelope-from ) for ; Tue, 15 Sep 2026 11:02:08 -0400 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=TMJk/kdY; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 54C361E06B; Tue, 15 Sep 2026 11:02:08 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_INVALID,DKIM_SIGNED,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 B9D841E01F for ; Tue, 15 Sep 2026 11:02:07 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E44B04BA901E for ; Tue, 15 Sep 2026 15:02:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E44B04BA901E 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=TMJk/kdY Received: from omta36.uswest2.a.cloudfilter.net (omta36.uswest2.a.cloudfilter.net [35.89.44.35]) by sourceware.org (Postfix) with ESMTPS id 364354BA79BF for ; Tue, 15 Sep 2026 15:01:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 364354BA79BF 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 364354BA79BF Authentication-Results: sourceware.org; arc=none smtp.remote-ip=35.89.44.35 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789484496; cv=none; b=kOsn75ZxLhzXYgpydbYdT0xgZz9L5U1Vpli1KV4oOBpii9xjj0PsSEVUuwU30H6rdQpqEdXvImIVnNVmx/5jJZd+3NQfekLTXsB5tpUq+mPPw+ahwu6Ch6kuWjMS0TSaUrilf3uPRrtGM5Hd3gbPHFMNJ6IKe4AKAVeB39Ih38Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789484496; c=relaxed/simple; bh=iYCQOHFLh54Q8fNPLw2wkX/67mG5c3jnWKsvX6lw0GA=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=oAZJ5ihmlb8P8FQVVyomzLZlxFaaCmHbnjKIhUpsj78XClW9uszCvbhpYMQlwETeQIETCxr1Sjs/R0RH1G3O/a5St23edd4DXuVa9M9fif0xClSA1lA1aujal6i2sEu6weuL4Wr2MiD4gGW0IP3PVfGcFl9Owa3tncU39y7yCAE= ARC-Authentication-Results: i=1; sourceware.org; dkim=policy (768-bit key, unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=TMJk/kdY reason="signing key too small" DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 364354BA79BF Received: from eig-obgw-5006b.ext.cloudfilter.net ([10.0.29.217]) by cmsmtp with ESMTPS id 6CqSxvSrGusRS6Uf8xSw3f; Tue, 15 Sep 2026 15:01:35 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id 6Uf2xDF7p5NF36Uf3xO0S7; Tue, 15 Sep 2026 15:01:29 +0000 X-Authority-Analysis: v=2.4 cv=GaMXnRXL c=1 sm=1 tr=0 ts=6aa95dce a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=VdqzKS8jKosA:10 a=ItBw4LHWJt0A:10 a=20KFwNOVAAAA:8 a=rY3CtMr7-i2U20z2kE8A:9 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-Unsubscribe-Post: List-Subscribe:List-Post:List-Owner:List-Archive; bh=2Jyj79rFVrP1W8afw1CYC5mBZOwoRupQOnnnmkNlYaE=; b=TMJk/kdYQBny5Lt7fjbOQYrmga 7ih3Nl4WM8Y6TwmBuJZv0lh8ZX495W/k6NXIEf4de8rutVotNbeJEfG1xpFspiI5sWI3vw1MJWk1t X8qHc/sc4NSw1ommirmwjqpsV; Received: from 75-166-229-74.hlrn.qwest.net ([75.166.229.74]:58870 helo=bapiya) by box5379.bluehost.com with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.100) (envelope-from ) id 1x6Uf2-00000000Iix-1fAI; Tue, 15 Sep 2026 09:01:28 -0600 From: Tom Tromey To: Andrew Burgess Cc: Simon Marchi , Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCHv3] gdb: resolve class name via DW_AT_signature in cooked index In-Reply-To: <875x06dd6f.fsf@redhat.com> (Andrew Burgess's message of "Tue, 15 Sep 2026 11:25:12 +0100") References: <295672ce0ea0bf20911fbbc997f38fe9f62b19be.1787952498.git.aburgess@redhat.com> <897f5eb957bdfd90cd3fd5efa662021ed5c2aef2.1788269262.git.aburgess@redhat.com> <1a67b29f-e2f1-480a-ae2b-e0d0d5acfdca@simark.ca> <874ifvy4u7.fsf@tromey.com> <87ecewc6gn.fsf@redhat.com> <875x06dd6f.fsf@redhat.com> X-Attribution: Tom Date: Tue, 15 Sep 2026 09:01:26 -0600 Message-ID: <87y0d2v9rt.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: 75.166.229.74 X-Source-L: No X-Exim-ID: 1x6Uf2-00000000Iix-1fAI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 75-166-229-74.hlrn.qwest.net (bapiya) [75.166.229.74]:58870 X-Source-Auth: tom+tromey.com X-Email-Count: 3 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfH7RebYhEvRjLFVzu5LhABzcTeWZAFbpby/NbgJapculDxn1c8LsIBlWkVi93N6f73BpJ0KZwUiTi8NNWBEDOflwAEruljoTcEc+bypnJqIYvRyR3XCq wJR24jinWKHdYzGeOwGd1uAK8WgkYadRw52Q6x8xgkOS5iSqML9ld6JdM7dG9VT5aq0/2xGJQkOMaayt+V3BvAAx5ZM3hm40Uw8= 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 >>>>> "Andrew" == Andrew Burgess writes: >> We would have to delete the name-less entries, and any child >> entry that refers to them, not sure how to do that efficiently though. Andrew> This is the problem I'm currently trying to solve. Andrew> The problem with this approach is that the parent might be from another Andrew> shard, potentially resolved due to the IS_PARENT_DEFERRED flag from the Andrew> parent map. The race is on the read of the parent's name field, the Andrew> parent might appear nameless, but it might in fact be the case that the Andrew> name hasn't been assigned yet. Andrew> The other possibility is that, because this is an error case, we could Andrew> have a serial action that cleans up the mess, deleting child entries Andrew> with nameless parents. This would be done in Andrew> cooked_index::set_contents, as part of this code: Right now your patch is fixing up these entries in parallel, in each shard. But if this is uncommon enough, it could be done in cooked_index::set_contents instead, say when setting up the finalizer tasks: for (auto &shard : m_shards) { auto this_shard = shard.get (); const parent_map_map *parent_maps = m_state->get_parent_map_map (); ... signature->entry lookup here Then entries could be filtered out in cooked_index_shard::finalize if they have a "bad" parent somewhere in their "parent" chain. I'm not sure if this would work or not. TBH I find all this stuff in DWARF pretty maddening and also difficult to reason about. Like, even constructing the case you are talking about seems very tricky, seeing that it has to involve type signatures and somehow also cross-CU parent references. A different option might be to ignore such entries at lookup time. That is, let the child entries stay in the vector and just skip them in the relevant lookup loops. My intuition generally is that DWARF reading is slow and user-visible, as is CU expansion -- but the lookups themselves are not. This would probably just mean touching the index writers and cooked_index_functions::search. Perhaps the bad entries themselves (an entry with a signature that couldn't be found) could simply not appear in the shard vector, to avoid problems with their anonymity. In cooked_index_functions::search you could just stick a check here: if (!entry->matches (search_flags) || !entry->matches (domain)) continue; Like "entry->valid () || ..." I have no idea if this is helpful but didn't want to leave you hanging. I'm sorry you have to deal with this. Tom