From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 6UWVDx6CqmrnOBIAWB0awg (envelope-from ) for ; Wed, 16 Sep 2026 07:48:46 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fIzZ5b81; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 3BCD01E06B; Wed, 16 Sep 2026 07:48:46 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 69ACC1E01F for ; Wed, 16 Sep 2026 07:48:45 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C24C44BA79B3 for ; Wed, 16 Sep 2026 11:48:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C24C44BA79B3 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fIzZ5b81 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTP id C5F514BA2E30 for ; Wed, 16 Sep 2026 11:48:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C5F514BA2E30 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C5F514BA2E30 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789559299; cv=none; b=xZz1YfVWng2TZ6dXKf766VBuF1qS3NTOvZU9kAi/dglNg0zfhNZNspTIeMcxo+sED9cVawsGm400TxAK/xVVL0QXHs7R18l4wtRT5iqpFPksTI87qTTGz4iwSqE9H9VbgB6wur+JHT40xPOnaGFVnkGdHI33x8UCRwNcVNvneNY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789559299; c=relaxed/simple; bh=BGJjHbJyqOsvM2Jmby64JwYWFFVgAbtIX5JCYNIdVjQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=PI6KtMHENDOPonsNePSR4QhT2YcHslRv1CgLu9EP+TfgrquLQlXw5YxKhQ3FuxGzQqMRuew3sdSUY/cMZaLF2AuYkzpn9X+cH1D3feKvUB6DcpEmk59R+FXH7QVq5NFkT6yN6pEV+7QqmSEiLGQ5cM/9M0CfVhz6cvg/BEJWgyQ= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=fIzZ5b81 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C5F514BA2E30 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789559298; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=cXYkJbTogzmCLmSHXBNNv0rEW+7gzhmQA31guRKKBdE=; b=fIzZ5b81K1fCdAeGqHGhM3DcM/i5lzK90OP+mS8sQBmLK5aeq1qxeTio1o+1/KLtCwqqqG 4VNjVnN/jWKPu70th6hsO3Ucyt7V6Na5FGcn1rNC+lGBwUl2kJ6aImMs4N1nsZkf8i4/2A r4JY6MXsBf+WNDKiuRGwQ3Gwfwb7FbM= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-461-RPR4-kAaPnCWbvBN7yVi0w-1; Wed, 16 Sep 2026 07:48:16 -0400 X-MC-Unique: RPR4-kAaPnCWbvBN7yVi0w-1 X-Mimecast-MFC-AGG-ID: RPR4-kAaPnCWbvBN7yVi0w_1789559295 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-495689bfcc8so45789415e9.1 for ; Wed, 16 Sep 2026 04:48:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789559295; x=1790164095; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=cXYkJbTogzmCLmSHXBNNv0rEW+7gzhmQA31guRKKBdE=; b=QIQuk2/CzHDT6vcqED5CEc1DYCOHED4ZJS6dEwF/Wd3jnib/v4MeCJ9ki0D83HL8qe ojnZb3ylsuJk/COMzkJmRUXLTNyvDuzhTOIF82+c+hNmBxt9SA3BxmEhfswhXJtq3QRn ECZ0uR5xdmOM08VhlwkyxBc6T5ERvBRoCkBViypY14+a481+PACkm3KU7VZjImP51Tct f3IRdvlkc3DpUgOvPA7CaW1KHcpHKle6I0/AkIMDua1RkBkhuV1CUyZuCqct5yKWtdz4 mrV4pLoX9JKPZLygSi+gLfGuoiW5Hd7UjKb6Zw4FyRmblRKll9mCeQosrHqyhcMy+0Ho 4CoQ== X-Forwarded-Encrypted: i=1; AKwUvBw9lLUeMOfS3gL2Vu/GEQewfiZgDTSd5w893ihLqRcpMflBXz8TnbGgXmsCeMuv4BSRwlJPQmuuHmA1MQ==@sourceware.org X-Gm-Message-State: AFuF++mEJgGFr0xXcfz98HhvbFTVd8rQojFJpZeow/lvdBB9Ew5XT3au BF/Qt0vmlw7n4To72KZdZRDS0CvZ9de+7D1aSVH108Qew8WmAKvfeXyxyufCFcYgOWPnTnGmctu wX7OuegPn639NF31U93jkDqdlgqWygJpheIdA/VMd4N0R2Dgztv3fz57QY+w9EE0= X-Gm-Gg: AYBFou3RKGr250sbJ4X9tJxHA9WeAlYJqTow9d7n11QT06gSLRPC6GK7N0CDbz0ethk 06OUSaBg/cBBDRQGZCGRxJVg4Y+GiGEwljw2VcCVnwjVsfBm5+J1yuMI31doPa2L0V1cLx7F6EJ 8DNKt4YS1fIuIbyE09Cue3IGYcsh8u1jyEaR8CVK4fOR4F2M9rA4cxA/LA63gcMms9NfLzbwyet Vp9uyrAhFaBaAHwUiYxqrIP70LgAzqlmKXmNJvcmxmjlGFD3K94HigBK6IU+RFVsAaJFAAXMs76 6Eo4/CiroexKdDS54aMvGbX0Qj8r3VDgCa9lpwUHPmlrOOj7Lr31vgBqSTiyzsZ6zQtNxjzVIxG gCInvDMtDr8crTOdL X-Received: by 2002:a05:600c:46d1:b0:49c:c0d4:53d9 with SMTP id 5b1f17b1804b1-49eb72fbf26mr25688525e9.14.1789559295472; Wed, 16 Sep 2026 04:48:15 -0700 (PDT) X-Received: by 2002:a05:600c:46d1:b0:49c:c0d4:53d9 with SMTP id 5b1f17b1804b1-49eb72fbf26mr25688135e9.14.1789559294963; Wed, 16 Sep 2026 04:48:14 -0700 (PDT) Received: from localhost (59.6.93.209.dyn.plus.net. [209.93.6.59]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e83d903f6sm69750385e9.4.2026.09.16.04.48.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2026 04:48:14 -0700 (PDT) From: Andrew Burgess To: Tom Tromey 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: <87y0d2v9rt.fsf@tromey.com> 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> <87y0d2v9rt.fsf@tromey.com> Date: Wed, 16 Sep 2026 12:48:13 +0100 Message-ID: <87tsnpbeo2.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: HefCV8KWI_XUMrMuDsypR7mL2Xp8Co705ZZCvYjInz4_1789559295 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Tom Tromey writes: >>>>>> "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. Not a problem, and it's good to learn more about this part of GDB that I've previously not worked on much. I'd already written v4 before I read this email, so I've not taken all your suggestions on board, that's not because I don't value them, but I'd already written some code which I think is OK, even if it's not exactly what you're suggesting here. I'd value your thoughts on the v4 patch, and if you see problems then I'll take another pass through this email and do something more along these lines. Thanks, Andrew