From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 4aFTKpSBqmpPNxIAWB0awg (envelope-from ) for ; Wed, 16 Sep 2026 07:46:28 -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=DTKe/pBC; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 75E031E066; Wed, 16 Sep 2026 07:46:28 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.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,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham 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 9CD371E066 for ; Wed, 16 Sep 2026 07:46:26 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C6CA24BA9004 for ; Wed, 16 Sep 2026 11:46:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C6CA24BA9004 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=DTKe/pBC 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 2A2314BA23FF for ; Wed, 16 Sep 2026 11:45:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2A2314BA23FF 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 2A2314BA23FF 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=1789559159; cv=none; b=D9SexECbmRBH6uMPQV65fEBSozqH/PKk6NUCbqKFuRmO1sFB5rkjoYbnZWMoa/pjwDiTlpdq1ROa8PfkgORxoeiBsTXAiPdn5hbf/POr3DFgotzCQUpP7yIh1iJfhffPQ/U0r8kRF9qZAFcT76Zy9huDw3gkcBVaS1sTJUtLwwA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789559159; c=relaxed/simple; bh=jDMTtfb1P0DjUV2LbHWWY28JU/BKPnU6wNIZGuhuMi0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ujHBDtDmZfkr5wrDGxfluXIvpqAeakarlgNKmzHBYmHgYWBZ5lVcLH2DkVC7dg5JQfjnCp7SkeYnTmRgQBo9GZBHByWKY4t9FrTe5dcVQhCvEUUJShm4Xk16dqu8Pbcrey0SYA77pa8CPZwX1rKuYpu2SuvFNeZmMEC3t8JpgKE= 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=DTKe/pBC DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2A2314BA23FF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789559158; 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=BjXXkvIYqTosPHGcdeTIAFmjHBDYMRUKvwtVB7zLpR0=; b=DTKe/pBCADaTmK5aRGO7xgYXUqDIocTuyeLvNsWZMZbsbfydY0/vxd3Fvw8GETAJXNhjfx wQBm6MoC5b0E4SNk9JgrRE5YRKk2RnOendD4tUozJXtCbhKkWsJFiJvcc46UDn5wQuyA4J svJ5q0RTnH360/i0L+4/nT92R7UMtqE= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-543-egdXalhxMLS64vw8rVeahQ-1; Wed, 16 Sep 2026 07:45:57 -0400 X-MC-Unique: egdXalhxMLS64vw8rVeahQ-1 X-Mimecast-MFC-AGG-ID: egdXalhxMLS64vw8rVeahQ_1789559156 Received: by mail-wm1-f72.google.com with SMTP id 5b1f17b1804b1-49e6b5c5f44so35852945e9.2 for ; Wed, 16 Sep 2026 04:45:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789559156; x=1790163956; 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=BjXXkvIYqTosPHGcdeTIAFmjHBDYMRUKvwtVB7zLpR0=; b=LtTPPQvkCKoRDEWVtoPDnUOB/yPHSap12uI10fbGRvQsOq8ZM+vks3t7fjcEwGxyx5 jcdAMAxfFMWaq01tyF2e3qSGlJHB39forzb296cgSUxiXFhJVtcHtrJUV6fk+bUTpyat B2jfhrkjhW6tfB/5ujXzW2116H1xyZRnQIK76XXuCGcvAwbUvJGmZ4oyriSl8CayDJIO 9P1I92pWf0QR5ALD/JQSj+zISzfRzNzaoTGusgRcSfOxa5Nlo9jv+SmHJ2gG4Zmy5y+5 OmBMCDNlMEJ8F1Qb6UA9isg7xkqih12H0bUWZiwV6hR0Y4RvzLMH791JqIz/eM2jnv/0 2H8w== X-Gm-Message-State: AFuF++mBhwy4e8qLGRY3uc6+lKn3hRcvo/HEkuD8kRUZ+iS23GeL7v2n CR575d7GT21UoR2S+FK5aSjLx0saZpd0Pq2/Vc4jx88QwheghJ8A2Rye3QUpeJVVcDgNc+ZXIQC K2IOLF6H3eF+EZuHrE0bl+jQWyfeL49use48a+lJu9sN7sz5RnmFjNnQfnnXUAUA= X-Gm-Gg: AYBFou3lvygELqxYnrpJQzrzH3uCP6ExiPpzSOtxsSqfMAtC7h/HYXOghStz3v1uW+o jl9AhjkUK3oBq77XXZpbFPwCUSBu2tuMxj2P0thjDxXYadXy1BqZpfJow85m248Il8Fp0pPzm7v aeFlLW4elP4rsXolOTXATyxlV+f/PgDHKH2qvIcy5axLJr8RMoQg4GIw6UYr1fsVHQXOCAh3sES JOY+CfJnVCQJt4EfC1iWJ4izHZn8ZxlR/HecAn5mb+hkIX1vVhJp0XX50Ob3mtzC345X9aKLrC2 Zh7kAZciNTPqNUTlpdbRefz//dBzJR4GfmoCUhtyQbkk0YEf/6C7EeEfP6qdTkw5O+Rv+hPqFCp 8z69yVEV8tC5affmD X-Received: by 2002:a05:600c:3150:b0:49c:cee0:f383 with SMTP id 5b1f17b1804b1-49eb7320da4mr26595175e9.16.1789559155694; Wed, 16 Sep 2026 04:45:55 -0700 (PDT) X-Received: by 2002:a05:600c:3150:b0:49c:cee0:f383 with SMTP id 5b1f17b1804b1-49eb7320da4mr26594755e9.16.1789559155263; Wed, 16 Sep 2026 04:45:55 -0700 (PDT) Received: from localhost (59.6.93.209.dyn.plus.net. [209.93.6.59]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e83a8d6e2sm75933565e9.1.2026.09.16.04.45.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Sep 2026 04:45:54 -0700 (PDT) From: Andrew Burgess To: Simon Marchi , Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCHv3] gdb: resolve class name via DW_AT_signature in cooked index In-Reply-To: <8ff7fcd2-f79c-48fc-9730-fbaf4dc17ec3@simark.ca> 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> <8ff7fcd2-f79c-48fc-9730-fbaf4dc17ec3@simark.ca> Date: Wed, 16 Sep 2026 12:45:53 +0100 Message-ID: <87wlslbery.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: WsAAbLWiWAwVRyLma2A5r-eQ_ZH2VQNwCRx0_lpYojI_1789559156 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 Simon Marchi writes: > On 2026-09-15 11:01, Tom Tromey wrote: >>>>>>> "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. > > Having a bad parent is rare, that would only happen when some > (nameless) type has a DW_AT_signature and the matching type unit can't > be found. That would be a buggy producer that "forgets" to add the > necessary type units. > > But the basic case where the name fixup is needed isn't an error case, > it's just what happens when using clang with -fdebug-types-section, > since structures/classes are nameless: > > 0x0000099e: DW_TAG_structure_type > DW_AT_declaration [DW_FORM_flag_present] (true) > DW_AT_signature [DW_FORM_ref_sig8] (0xdf1329ababfff8ca) > > So I suppose you'll get one fixup to do per structure/class type. > > Doing the fixups in parallel is easy, since it's just looking up the > signature -> maps, and the "finalize" step already exists, so why not. > >> >> 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 () || ..." > > This was our earlier suggestion. Leave the name nullptr (or set a flag, > whatever), marking them as invalid. When you need to compute the full > name of an entry, you walk up the parent chain. If one of those parents > is invalid, bail out. You can't correctly an entry's full name if the > name of a parent is missing, as simple as that. And then you have to > handle invalid entries in a few other locations (like > cooked_index_functions::search and the index writers, as you said), but > it shouldn't be too bad. That sounds simpler than trying to remove the > entries. I've just posted v4. The approach taken there is to orphan entries that have an invalid parent during finalization. After that I just let things play out as they will. This means that something that should be 'the_type::method' will be added to the index as just 'method' IFF the DWARF for 'the_type' is broken such that the signature based lookup for 'the_type' fails. I think this is the same result as you've get by leaving the bad entries around (i.e. linked via the parent pointer) and just bailing out when trying to build the full name. At the end of the day, if the DWARF is bad then anything we come up with is not ideal. I guess the gold standard would be to remove the bad entry and all its (grand-)*children, but that's super expensive, and doesn't seem worth the hassle for something that should never happen. Anyway, you'll need to check out v4 and let me know what you think. Thanks, Andrew