From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ISvGG2z1p2rWGAwAWB0awg (envelope-from ) for ; Mon, 14 Sep 2026 09:23:56 -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=MMT9SEFq; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 663B81E066; Mon, 14 Sep 2026 09:23:56 -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 A666C1E01F for ; Mon, 14 Sep 2026 09:23:55 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B2ACB4BB1C1F for ; Mon, 14 Sep 2026 13:23:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B2ACB4BB1C1F 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=MMT9SEFq 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 EA9734BAE7DF for ; Mon, 14 Sep 2026 13:23:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EA9734BAE7DF 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 EA9734BAE7DF 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=1789392208; cv=none; b=Bb8mIXCVmkOEYDJXWhYW98/ELvinNdMp4uflf63s0mKSyUS7nOTtN94Ozx10fUBj0eCFfYwnJXkX49sVEP6lzUFptUAaJjqC04oAvGdRpwEo/UHkgL12C4dmJGlODKwqBiDRBvmWO6Ruk2QiW7sz0y7mJbgXq6rXPpH4BxcQ+7A= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789392208; c=relaxed/simple; bh=Q269SKkDFlfT8vRMpFleHFLvPsjTrsCcYcgGJrcPhjU=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=dmu86a9WmccahfwNtr1V/DTZjveXluwkd1edP7qcw8zfuIM5ZNkBk2I2HgPK1jUTlfsSf8PeZ6sIoU/J2DNAXOJ4E3qxZPMmTgd6VNnbUKH6VAVaQzp59swHFQFA3jDw9+cKdWPUFXqH06AP08EHPsMBxTzFnNcdkv/ZESGGkwU= 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=MMT9SEFq DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EA9734BAE7DF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1789392207; 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=moh+f6kD3eaMbS1MAawGCraojyKPr9DlGmX8PhlfzeA=; b=MMT9SEFqQSLfM+eiZ2EXnExkOz4xoDWFTmTuQaY1SkqhM8utsMHwEGU3jaKe2ORQCfo9b8 vZBHiItvB+NmGzuvWOZsMnDJqWGiCKBHFKW4W9h2eFUc2j+39dki+qrab7YWQEEhGDQT6O GEtcLfhE9X3VNksomqqBIeLF2zQH7e8= 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-424-AgE3xYERPFm3x24cVmVIlQ-1; Mon, 14 Sep 2026 09:23:26 -0400 X-MC-Unique: AgE3xYERPFm3x24cVmVIlQ-1 X-Mimecast-MFC-AGG-ID: AgE3xYERPFm3x24cVmVIlQ_1789392204 Received: by mail-wm1-f71.google.com with SMTP id 5b1f17b1804b1-49cf5bd2f12so35550815e9.1 for ; Mon, 14 Sep 2026 06:23:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1789392204; x=1789997004; 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=moh+f6kD3eaMbS1MAawGCraojyKPr9DlGmX8PhlfzeA=; b=IPsSJikcDpb9ALGsRrjgkXzHNdGOPGnAk3NuWZJoQc9Dc4oIueZZtQc4AFBIVcpr6Z X9qlLlVVSXLmLRYaac5cnvd4w4gMYRP569Yeo1RO7bvN4deeWT2BvpbbjEHB8+0Bh03V bRZ60kzB2frqesE362R8yPB+tGW68AuJysvazIzaKY2ZJ9KXD/Rkvi9+7OSgCydS3rQp ptQIBCgj0ZxeR5H72P4lbTGYaT17EgsSHxkmXOaRnPkF2uXQabanvabgMCWDAD4yjBZX zsym4nUD3fmd7An4jqGlPlbfRVa/rY7ECh7KtTBs05z3/sdc6dQ7ynGh46Ij8MWsrHY3 EzeA== X-Gm-Message-State: AFuF++lkIu78wypacqCacDqo6UNsyh8LUS0ZNyAOXJTPT+ZXwbNJmmHf 6MUbSxyCBwWaGTbMMQulwmHOpqnItmbUJDNSkKDyvAsIBy5awaSfUAikWuQbf4n9u6MJ8c+zwVw 7S/Dl66FmRkzLl5RopG3aKrG7bjDhcQjQqZZRnhJRGGti0RcEp7K9wYOZPStMQlM= X-Gm-Gg: AYBFou2EXd1x4dTgvOiXJKonXre6LA0HNgDvIKAUG/Q4X/c33JDwo5tvA+MeJO1tavr dKg+xPAAUO9bRgOxu4K8HzFq+1KnrlbGTOfIo++5+dMGNulOJiforgnOsaADi7boHH7iyLbPkR7 D51axlO+ahuIugwp4jrceI3r+NiFdRZfwbhIMVbigIMhEdRph856y5K0rLMcWCqcAe7l4LtI6SE Y65r1keO4uzRuvwpsuMl2LLp3VA/DaxPBHk02x+7BotY7yCwPsHecLttGGOffEXjC9fdQxLBMyT kAfRiQtDtA6YpCCzpKwPgFuoYSiAgF7hVSO0vf5zejzNBsvLhwm7lfYH+G7ejtDzTg+hsRauGIs 6p2TUQEX54dj+/nP9 X-Received: by 2002:a05:600c:4688:b0:49c:edfa:15a with SMTP id 5b1f17b1804b1-49e7a669474mr31880535e9.13.1789392204054; Mon, 14 Sep 2026 06:23:24 -0700 (PDT) X-Received: by 2002:a05:600c:4688:b0:49c:edfa:15a with SMTP id 5b1f17b1804b1-49e7a669474mr31879985e9.13.1789392203533; Mon, 14 Sep 2026 06:23:23 -0700 (PDT) Received: from localhost (59.6.93.209.dyn.plus.net. [209.93.6.59]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-49e7d202a2bsm1734395e9.0.2026.09.14.06.23.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Sep 2026 06:23:22 -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> Date: Mon, 14 Sep 2026 14:23:20 +0100 Message-ID: <87ecewc6gn.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: KlRNd3gY4hIfNciKajEyFPZUZonVJ2-i9HywgSOC2u4_1789392204 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-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. 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. > >> 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. I wouldn't want to turn these into debug prints. I understand Tom's point though, the complaints are off by default, and what are users actually going to do even if they are turned on? Usually the problem is one of the compiler's making, and the user is likely stuck. Still, it might be nice if we did a better job of altering the user in some way that we found issues with the DWARF, and some things might not work as they expect. I've long wondered if the problem is that the choice right now is "print all complaints" or "print no complaints", but that's not always that useful. Users likely care even less, or have even less power to change things, if the complaints are from some system library. What if, instead of printing the complaints (or not printing them) we instead stored the complaints somewhere, and associated the complaint with the objfile for which the debug information was loaded. Then, before printing the CLI prompt, we could inform the user: 123 debug information complaints seen. Use 'info complaints' for more details. (gdb) then 'info complaints' would like each objfile and the number of complaints seen, and 'info complaints ' would actually list the complaints for the given objfile. Having the output come from a command would also allow us produce more verbose output, instead of the current 1 or 2 sentence style, we could fully explain what the issue is, and what this might mean. Of course the 'xxx debug information complaints seen' would actually be 'complaints seen since the last time GDB informed the user', so the user wouldn't be constantly spammed with that message. > >> 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. I need to update the comment, so I'll try to write something that covers this case too. Thanks, Andrew