From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aYUCJC0dqWqQNQ4AWB0awg (envelope-from ) for ; Tue, 15 Sep 2026 06:25:49 -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=S0xliS1/; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 8FA871E06B; Tue, 15 Sep 2026 06:25:49 -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 12EE01E01F for ; Tue, 15 Sep 2026 06:25:49 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9C8B74B9DB67 for ; Tue, 15 Sep 2026 10:25:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9C8B74B9DB67 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=S0xliS1/ Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 4E69F4BA2E1D for ; Tue, 15 Sep 2026 10:25:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4E69F4BA2E1D 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 4E69F4BA2E1D Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789467917; cv=none; b=KGRMaSqUzutQZ6SkfdqeQq7iEbiqXccG3TJkY1xf4wEEKy1fHrQrujkUHZQF9FRnNTNCT6KR2HBXOpIvVOI4EJblVfzSs4NTtVigqrkwbowjQcZM9He7/LY1uFa0s77edkwu/a9TkDQIDIniX6e0o43AleCImal32mAIx3bv99Y= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789467917; c=relaxed/simple; bh=8toz0FwDDxJayN+luywmK0jIxHuJQ33HWXuMM/ygnfY=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=rhEqAv/nJO48ys9/tetiCWm6JPC5sgfLHC2i5x9IR+vdra/4XI2fZV8b3Z3Lb745eOxuvmCDP4un5set8tvNKohmNr+w7YjVF//qoEL4c5bUuoxhkRorYouYKisPSdEY/5cq5LBjldEk7Xbn6Lewr78beAw66fNoAPbgG3t4UJU= 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=S0xliS1/ DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4E69F4BA2E1D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789467916; 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=/NIXEH2gcqvIj4bUmWEl3djTKspPvOX4sc8wOx/kfuY=; b=S0xliS1/I9R3ENpuSNPwL85dko/C9TdQF4WcIs0qgC11g+fDa0zbTqyPw3zJ7HCGI8Aa6r 0Nrzahl2XMvMBBrePeCtydh+97676UXds1gBdwLXzdnfXydt5NW1LH8rfYqGDCdDENEZ8O 5e9dpf/qcBBbq1ijj3PosbSoEwPZMZ0= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-606-Q6IBeA9fNNiWN1xrZTpuHQ-1; Tue, 15 Sep 2026 06:25:15 -0400 X-MC-Unique: Q6IBeA9fNNiWN1xrZTpuHQ-1 X-Mimecast-MFC-AGG-ID: Q6IBeA9fNNiWN1xrZTpuHQ_1789467914 Received: by mail-wm1-f70.google.com with SMTP id 5b1f17b1804b1-4955e865174so22213025e9.3 for ; Tue, 15 Sep 2026 03:25:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20260707; t=1789467914; x=1790072714; 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=/NIXEH2gcqvIj4bUmWEl3djTKspPvOX4sc8wOx/kfuY=; b=AvvlYoAAW+25dB6wgLI+TbyviHmUmp7x6nIzjhXRgFW+jpN0G49NMRioUEAiicvC+D 3IS9FxRbsIkJx2VtV+ZpvQfC8WnVLb/qEtksWiG9URij7MTt8QaYsxGcF4bCu4wFlfy8 vRUWIfKxcgrCmb6Z/TRgW2XYoiZGWqFJ1HsJ4tR83igivgL7M5SfuaMRnI8YIcF9TeEL w7p1EWz5gudaqg4okGOz4S1IWzV6T4Oez/RlEbWwWvgshb0a0Vm8XWQGdFs0nQKpYfQe 0JjnmLIPAIV+KLR4eJhYJw8pjtTXVb0/o/FzzS6yoDWPLlQUeCoc4t7hl+0haDqxHibR Wl9Q== X-Gm-Message-State: AFuF++lnsBy1fJ2rzAEz2l24mUEG4SzNXUj/wi1zbW7MdhasbBN6RBas Zcq1TqELekZBV4WQFiy68Rcn+/XmmSEYtL/1dogZ9KoGnHyzMWd0pZNVdRGrtu4BxqwDiK9xgPn IpLwZp1x7ZnqvJt6hXqDg04CqBaYrU9m6PkgGfe/6tcwRYBgBXhYRu+AcAb8piBWq0wTqU6A= X-Gm-Gg: AYBFou2OO2HnrLZYj4e4SdIVKFP+xzaliEXvfUMwm1xgjnxMXcpEzFb6cnEOvQM/JrA mmbtd2uIZj+w/VfFl2ZnYMqmdhHhLWYcB0NnB6p9k8bm7AOsOJSqNRQeYJ+LCyApVl1RF3c6f8M pez+79Uh2gkT3BFLT5A4oDX+Zql2Bwr070n0ZB5VWi0UPnIspt+6MIpehwL6jpqVEov/5bblscC +yZQVIZ57y9xTOEfYmoI6tXlOEWeCmsPdRxe+Cdai2yNjOdYl45RaPNlYcnrXWQLyeTt6ZWjxQR BHKzhr2ASP94vU+HPtnmf6zeGq/cO4g/tytZUarqvBatQNq6dsgqrgoRwYQDOyovVi6IrJoeRzn KKiuNLFdWkXJicLbw X-Received: by 2002:a05:600c:a47:b0:49d:16f1:94a5 with SMTP id 5b1f17b1804b1-49e7a677980mr78314575e9.25.1789467914211; Tue, 15 Sep 2026 03:25:14 -0700 (PDT) X-Received: by 2002:a05:600c:a47:b0:49d:16f1:94a5 with SMTP id 5b1f17b1804b1-49e7a677980mr78314295e9.25.1789467913770; Tue, 15 Sep 2026 03:25:13 -0700 (PDT) Received: from localhost (59.6.93.209.dyn.plus.net. [209.93.6.59]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-486eb33ea60sm33189531f8f.17.2026.09.15.03.25.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 15 Sep 2026 03:25:13 -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: 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> Date: Tue, 15 Sep 2026 11:25:12 +0100 Message-ID: <875x06dd6f.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: Qk5WlOrNQh2a-9I_-B5u0CKRxMWxxOj8D2nVg4bAJi8_1789467914 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 9/14/26 9:23 AM, Andrew Burgess wrote: >>>> I would much prefer a new cooked_index_flag_enum value over allowing >>>> NULL pointers. >>> >>> Why? Just wondering. >> >> Also, in this case, the point is that we end up creating the >> cooked_index_entry before we know the name, so what value should the >> name pointer hold? >> >> My V1 patch tried to find the name before the entry was created, but Tom >> correctly pointed out that this was not thread safe, and would fail to >> find the name in some cases. >> >> My V2 used the empty string in order to avoid NULL pointers, but empty >> name strings cannot usually (outside of this patch) be created, and as >> Simon pointed out, if these empty strings "escape" into the rest of GDB >> then problems arise. >> >> So V3 switched to NULL pointers as something that is fairly obviously an >> "unset" string. >> >> I haven't looked into it, but I'm sure I could add an enum flag, but >> this would still leave the question of what value to give NAME until >> it's actually filled in. > > That's why I was wondering, but really I am not opposed to a flag, I > just wanted to know the rationale. We have 1 bit free in > cooked_index_flag, so it wouldn't take up any more space. It's just > that having a flag that says "this entry has no name and is therefore > invalid" seems redundant with the name being nullptr. > > Instead of leaving them nullptr, another option would be delete those > cooked_index_entries from the vectors, if we never plan to do anything > with them. This is what I'm doing in v4. The entries all live on the obstack, so I can just remove them from the vector without concern. But .... > 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. This is the problem I'm currently trying to solve. I also reached the conclusion that deleting the child entries would be too expensive, so my second plan was to just delete the parent pointer from child entries if the parent is nameless. This would leave the child entries in a weird state, e.g. 'the_type::method' would appear in the index as just 'method', but I think this would be fine. This isn't "normal" behaviour, and only triggers in the case where the parent's name cannot be found. The problem with this approach is that the parent might be from another shard, potentially resolved due to the IS_PARENT_DEFERRED flag from the parent map. The race is on the read of the parent's name field, the parent might appear nameless, but it might in fact be the case that the name hasn't been assigned yet. So the current idea I'm considering is leaving "nameless" entries around, but giving them a non-empty name, something like "__signature_0x..._not_found__". This name would then show up in the index, and a user could, in theory, say: (gdb) print __signature_0x..._not_found__::method which seems weird, but remember, this really is an edge case, for when a referenced signature isn't found. The other possibility is that, because this is an error case, we could have a serial action that cleans up the mess, deleting child entries with nameless parents. This would be done in cooked_index::set_contents, as part of this code: gdb::task_group finalizers ([this] () { // TODO: Fix up the state here. m_state->set (cooked_state::FINALIZED); m_state->write_to_cache (index_for_writing ()); m_state->set (cooked_state::CACHE_DONE); }); The fix up would be cheap if there was nothing to do, which would be the normal case, but in the error case, we'd search through and delete any child with a nameless parent, and their children, and their children, etc. Or maybe just clear the parent pointer at this point? I'm not really sure yet. Anyway, if you have any thoughts, I'd love to hear them. Thanks, Andrew