From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id BXoME9yzpGqFPAIAWB0awg (envelope-from ) for ; Fri, 11 Sep 2026 22:07:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1789178844; bh=yfGmpLZmDs7JeyyjKqavgsXfyKfLIFZIla33jylfk8o=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=NlEGJljdTX46E12pnaIzB4h4duqldNePlMQDGiwrAXs0U+NfB37+zkJ76BLdG8ELL 6rwWDbSkRT50qS9/7iGrMkmwzQ66t49A3Her3i298O6ARn8P4q0kBcMIQe6PRcMRjf to4jbo98nk+w5yaZX37E6KXBmCeD95hSpkBmN+AU= Received: by simark.ca (Postfix, from userid 112) id 3EC6A1E09E; Fri, 11 Sep 2026 22:07:24 -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.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 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=hyKxzrVM; dkim-atps=neutral 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 7A2061E033 for ; Fri, 11 Sep 2026 22:07:23 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9DB4148F60E1 for ; Sat, 12 Sep 2026 02:07:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9DB4148F60E1 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=hyKxzrVM Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 2E2DF48FE542 for ; Sat, 12 Sep 2026 02:07:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2E2DF48FE542 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 2E2DF48FE542 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789178820; cv=none; b=gVDgYQ40cP6DC8duQpDUfzLboeO0oDXzD5b+DY9z3oABqQU+Lyd0zwboxrLMLYmYAG6fH4dpUDlIiNJ0qJWVQ18dPEopMLIZUvGKHkkGvYbRbsxNlS9tsauHcaAsJKvbJEXQEZwEJ1Dx4rPN+AZQHGTrVmIrLVcuLMJUczrbap8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789178820; c=relaxed/simple; bh=yfGmpLZmDs7JeyyjKqavgsXfyKfLIFZIla33jylfk8o=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=k3+RLGGIw/aDj8jeMmm+WE1dEQFlsgrDlD+cES3TMlsv1JtnUkQWoDyyZ1JQ/CmcxeYesQlfTfbaaDJMmWE5V3T2FEEu4uIKosLkgNtVIipl7Nz+7NnzMunnIkpdnuyt4g2tgMb2Fy8bGuippTO514n2VKLA8ARBe/lYdyVH7VM= ARC-Authentication-Results: i=1; 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=hyKxzrVM DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2E2DF48FE542 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1789178818; bh=yfGmpLZmDs7JeyyjKqavgsXfyKfLIFZIla33jylfk8o=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=hyKxzrVMlhn0GSIaIi+7Hb039mqyrCJ9kLZ41MhmHRyhOcxl8LUdNB/NVSJmq+Bjx EeeDkQrEF7dqdg9wpB/dlE9JO6hmSicMbUzBr93Z6Jx/xbl93P1rWLqs7ttZ53twBJ onektIU0eVzLPGRfqL1EwxmTknhG0XbxS6rDXC1g= Received: by simark.ca (Postfix) id D5D021E033; Fri, 11 Sep 2026 22:06:58 -0400 (EDT) Message-ID: Date: Fri, 11 Sep 2026 22:06:58 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv3] gdb: resolve class name via DW_AT_signature in cooked index To: Tom Tromey Cc: Andrew Burgess , gdb-patches@sourceware.org References: <295672ce0ea0bf20911fbbc997f38fe9f62b19be.1787952498.git.aburgess@redhat.com> <897f5eb957bdfd90cd3fd5efa662021ed5c2aef2.1788269262.git.aburgess@redhat.com> <1a67b29f-e2f1-480a-ae2b-e0d0d5acfdca@simark.ca> <874ifvy4u7.fsf@tromey.com> Content-Language: en-US From: Simon Marchi In-Reply-To: <874ifvy4u7.fsf@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-09-11 15:18, Tom Tromey wrote: >>>>>> "Simon" == Simon Marchi writes: > >>> (a) If a DIE has no name, but does have a signature, then give the >>> DIE a fake name (the empty string), and create an index entry >>> for the DIE. Also keep a record that the cooked_index_entry >>> for this DIE has a deferred name. > > Simon> Just wondering, if we end up not patching the entry for some reason, > Simon> will an entry with an empty name cause problems / match things it's not > Simon> supposed to match? Like will the child of that nameless entry be > Simon> considered to be part of the top-level namespace or something like that? > > Simon> If it happens that we have an entry with an unresolved name, perhaps we > Simon> should consider this entry invalid and just skip anything that would > Simon> require it. > > Simon> So yeah, I wonder if it wouldn't be better to leave the name as > Simon> nullptr, that would force us to add some nullptr checks to realize > Simon> that the entry doesn't have a valid name, and we would skip it. > > I would much prefer a new cooked_index_flag_enum value over allowing > NULL pointers. Why? Just wondering. > Simon> - the complaint runs on a thread pool worker, but no > Simon> complaint_interceptor is installed in those threads, so > Simon> complaint_internal writes straight to gdb_stderr from a worker > Simon> thread, outside the collect-and-re-emit-on-the-main-thread machinery. > Simon> Besides the raw thread-safety issue, the message can land at an > Simon> arbitrary point in the main thread's output. Using the > Simon> complaint interceptor would fix both. > > Complaints are worthless IMO. > > If this is user-actionable or interesting in any way, it's better to > warn. If it isn't user-actionable, then it can just be ignored. I don't recall, are we allowed to use debug_printf functions in non-main-threads? I'd like if that kind of anomaly left a trace somewhere, that you can look at without having to debug gdb itself. Of course the debug output will probably not look pretty if multiple threads spew some simultaneously, but you can always disable background threads just for this. > Simon> - The comment on cooked_index_entry::name says that it always points > Simon> into mapped DWARF sections, which is not true anymore. The comment > Simon> could talk about the "" case (or nullptr if we decided to go that > Simon> route). > > I think it's actually wrong already since cooked_index_shard::finalize > can synthesize names. It's really the lifetime of the pointer that is > important, not the storage location; and the important invariant is that > there's never a case where the string is freed but the entry is live. Makes sense yeah. Simon