From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id JpHAJn4LqGqaQQwAWB0awg (envelope-from ) for ; Mon, 14 Sep 2026 10:58:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1789397886; bh=/JrNjUPYrllx1acCw45AFq75yPdPBsdDjMXh1qb9af4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=GGKsVHTrDEPx7eE9hEUn0AFFwtON5lM3DHwb+gPT7lQeZGyJNJoLuCEkok0351u4N DRvD19PJFEpGtUEH8BUGhZfsDDZhYY+bmugfpE6jA863EH2L0/HofLhEmN2YYpkbwi yBbh4kt2bDWMJH89JqHGu8GEQ+0QSpjsdXHs8jKc= Received: by simark.ca (Postfix, from userid 112) id 8CA591E01F; Mon, 14 Sep 2026 10:58:06 -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=EIq2Ddjl; 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 0D72B1E01F for ; Mon, 14 Sep 2026 10:58:06 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 47D684B99F7E for ; Mon, 14 Sep 2026 14:58:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 47D684B99F7E 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=EIq2Ddjl Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 2BE5A4BA79A4 for ; Mon, 14 Sep 2026 14:57:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2BE5A4BA79A4 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 2BE5A4BA79A4 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=1789397862; cv=none; b=wiyjcIEfEMwHXO4mrV67NncSRxnBJqNhKVLONcTThXv7ofqL3zngEi1cehMvhhLpMI5t9dVeeXVanaciL7/WRkDv6ArGgg2MX83FNyPDKbf4MVO5u5urkUDmWnOyBaGN7p0vh7aLxQ+hEN6xRtjM3eSHHe3T7KutK4z9qNit7cw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1789397862; c=relaxed/simple; bh=/JrNjUPYrllx1acCw45AFq75yPdPBsdDjMXh1qb9af4=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=P3Ln3+vGuhEYlYqq2qQjVATa20gIf8skE/ZZjPDC7Y/Gmpzo7NK1JXkw7QvB6NkOcWecAuKxihfUc8r5DEisxZIKV6krovgCgvBIX/aIoSCjvxWkhbx1Pah0Pd0d+8daqhBcSTdkZPytTb0+qLfxeUeHrFU2ZA+2BuvNf8GUyx4= 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=EIq2Ddjl DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2BE5A4BA79A4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1789397855; bh=/JrNjUPYrllx1acCw45AFq75yPdPBsdDjMXh1qb9af4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=EIq2DdjlmdFsYv2VGiv7hCu9B+N/ap2JhcOE1PEK5ziFuiIVw0Ke60El9/Wn5eKEL Rp7QR3uSCG01MAsWHRKCzMJJ1nUAYW6SW/LTBrCMHBCpe2bxauwN5Oss5iCkfyREtD ncvm7CCTIAVkiPcwfTX1dIjby80L4kQPOTo4bJf8= Received: by simark.ca (Postfix) id 09D6A1E01F; Mon, 14 Sep 2026 10:57:35 -0400 (EDT) Message-ID: Date: Mon, 14 Sep 2026 10:57:34 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCHv3] gdb: resolve class name via DW_AT_signature in cooked index To: Andrew Burgess , Tom Tromey Cc: 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> <87ecewc6gn.fsf@redhat.com> Content-Language: fr From: Simon Marchi In-Reply-To: <87ecewc6gn.fsf@redhat.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 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. 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. Simon