From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id M5d8N8yf+2lUUhsAWB0awg (envelope-from ) for ; Wed, 06 May 2026 16:08:44 -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=UOXMxYO8; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D15781E0BA; Wed, 06 May 2026 16:08:44 -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,HTML_MESSAGE, 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 BF2BC1E067 for ; Wed, 06 May 2026 16:08:39 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4364B4BA23D2 for ; Wed, 6 May 2026 20:08:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4364B4BA23D2 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=UOXMxYO8 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 D5E754BA23D2 for ; Wed, 6 May 2026 20:08:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D5E754BA23D2 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 D5E754BA23D2 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=1778098092; cv=none; b=MVzwM3fgMRTfITmuZmJJpOdmFVM8wn7AiglyyxGA8ZJPsOJzKInwn9Q4UWecskveLRnarQq2u7XjQOaGnGOCzwf8VpYU9+iYQeUZS2Q2Hz81KvqXHWFoNxig7NWgJn5hJx3qqSVwrcyVKuXZIN8rllpAUREHM/kDosFXL2RQ10s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778098092; c=relaxed/simple; bh=HiHNqjfWnWi450wQFWX36v8pArx2TUZkDNgzejgtaMg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Ib+y9k0i0K70YZX3DubTu96fnF/1WOjMWki/HHxnWEOLr6hD1Bqn0iA4LUptnbtkF2rY1L5pwPIqUMevK07xLdZPOxQLbI2aqJSlbSadcBrdP8KGTaRBaz+EGxMngxZ1xeOgBi4vq5b9h+eUyXwBJ/jVqlao+UxfHLwpxLAnJiM= 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=UOXMxYO8 DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D5E754BA23D2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1778098091; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Rt76hqR94PkG8fB3pnVkzLVQFOoIgLwcM6L+X1+x5Eg=; b=UOXMxYO8hAYcL3XW3MWsGI9oSalmYSECJZpnANPz65Q45z6enZ1uKY/z2bwO1YyjyJUd7O 5MpMA2ds9pnissnKB7xIrKXLPeLpZrJk4Xw/EQeAL19viVZffjJ+t8vllpwEXNrGXfFJM2 A0ycMye615jkLHfpy/9RfwR96qdTwzA= Received: from mail-dy1-f200.google.com (mail-dy1-f200.google.com [74.125.82.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-412-2rOHy2hlNjiwKdjBCy62Xg-1; Wed, 06 May 2026 16:08:07 -0400 X-MC-Unique: 2rOHy2hlNjiwKdjBCy62Xg-1 X-Mimecast-MFC-AGG-ID: 2rOHy2hlNjiwKdjBCy62Xg_1778098085 Received: by mail-dy1-f200.google.com with SMTP id 5a478bee46e88-2ee34588671so166024eec.0 for ; Wed, 06 May 2026 13:08:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778098084; x=1778702884; h=in-reply-to:from:content-language:references:to:subject:user-agent :mime-version:date:message-id:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Rt76hqR94PkG8fB3pnVkzLVQFOoIgLwcM6L+X1+x5Eg=; b=CWyMXrB2xeCWruRfQC1GxM1XMOipY0sK+h+g6tKNdZKD4HgQwbmMA5rhfQn589kLxf Booj5qWvtWWTeanEIlGBmI9rOpn3dXI4iDhfOarW/HdBIS5UXZcrKjk4L1e3tPGkIYu5 BJeYe+dRavCotYlmE7ZuK6zh2ZdB4Q0M9JsKQWrMovf3cE8asgGzR/mCP6FPiH3Dncqh aH5yFCTxOubtNVeKcVoylcy2P8dT/EMLdpph74lbSlkSOQW1LLSWOQ3xDUK01/STGtt0 WrK/jNvwM91idWEBgYKM015y3Re3u4ZafVdrKpSJaUwYhLcvQ2rck/GtKSxNVqkggWu2 vw7g== X-Forwarded-Encrypted: i=1; AFNElJ/WZ2WPnTdP2paULygy+MALpLz1xfOUwSipkZEdvHEvgXmJVovFz+x6z+4aQ0P90URQj8IQILl+n7VIwg==@sourceware.org X-Gm-Message-State: AOJu0Ywv0NWueyM74KgYS+8JbGOmeqFR9N3NcmyqVMqSaThdhhqfEMNw hv/OxiLBW+SKY3tXeVsZfNjxLFfSL29dBY+6jyiRLxSFx0zjL73+1f/fiJyAgcTnHsc13E7mg39 y/PpimrxyNId/s3IrkFGxyCKAzldDEV2qqxuFgK2MIOWYtWTNtcpKlx6m8yiQ4MykCExYGXY= X-Gm-Gg: AeBDievglR84UNHbCS2RtYJqqbwKgJp0yosRoBCPz9UCpJoxVhCFdWWxZCa5xU1I8gy VFhVh+eK1JwvlUw5uxMXc/PikwUzf4kS1TPPHtwq1eTDz7UiBcwGQ2PrfJ6rUyvlwhNFtrPBt0B ImrGY78vvoJ3KKi7xAs8HB6tJUCJClTa3MTqdtyvmB6HOEFAJxiW8XSxFNz+BkhOAWZBnZL2box yaH5K0uFoL5d/bR8qh8IjxDrc1aVUY34U7KjqWq/dKkh1jUiH+Vi/Nv62mjbrqFcIU1B52xSqFf 6GS4ByAmFAXmlXYDzUlpGxS0O4jg3GG/ufcKpaTJFlBxNiBQQh7KxW/hQ1LXNYvrnyqc32vZgHR u8EdrrMBscT4WNzcrQI0ehp6YsvmcxJqcUr99yElpcONBJACtANf3 X-Received: by 2002:a05:7022:fa05:b0:12d:de3f:f3e2 with SMTP id a92af1059eb24-131964a431fmr2444130c88.44.1778098084501; Wed, 06 May 2026 13:08:04 -0700 (PDT) X-Received: by 2002:a05:7022:fa05:b0:12d:de3f:f3e2 with SMTP id a92af1059eb24-131964a431fmr2444076c88.44.1778098083938; Wed, 06 May 2026 13:08:03 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:993e::75d? ([2804:14d:8084:993e::75d]) by smtp.gmail.com with ESMTPSA id a92af1059eb24-131f9789e3dsm5193042c88.8.2026.05.06.13.08.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 May 2026 13:08:03 -0700 (PDT) Message-ID: <05e944bf-5c44-4201-b74b-ca6bdfa0289a@redhat.com> Date: Wed, 6 May 2026 17:07:59 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v7] gdb: Print linker namespace when showing a frame To: Andrew Burgess , gdb-patches@sourceware.org References: <20260113174341.3532973-1-guinevere@redhat.com> <87se8p38al.fsf@redhat.com> From: Guinevere Larsen In-Reply-To: <87se8p38al.fsf@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: rZiCLlVrWJr4UamJgE_LRvJLHiVELJAk4CsBf6IhUFY_1778098085 X-Mimecast-Originator: redhat.com Content-Type: multipart/alternative; boundary="------------99XuACN6wY9TEhf98FR8KcqX" Content-Language: en-US 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 This is a multi-part message in MIME format. --------------99XuACN6wY9TEhf98FR8KcqX Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 4/20/26 1:28 PM, Andrew Burgess wrote: >> @@ -1288,13 +1290,13 @@ find_frame_funname (const frame_info_ptr &frame, enum language *funlang, >> stored in the symbol table, but we stored a version >> with DMGL_PARAMS turned on, and here we don't want to >> display parameters. So remove the parameters. */ >> - funname = cp_remove_params (print_name); >> + funname = cp_remove_params (print_name.c_str ()); > Does this work? The PRINT_NAME will have the namepsace prefix in place, > but doesn't cp_remove_params parse the name as a C++ symbol, so will > this correctly find and remove the parameters? > > I haven't looked at the earlier versions, but I have a suspicion that > this might be me causing problems, as I think originally you were adding > the namespace-id as a prefix, and I pushed you to write > print_name_with_namespace. > > Anyway, I think you should write a test to cover this case (C++ symbol > in a namespace) and see if this works, if not, then you might need to go > back to something more like your original approach, adding the namespace > prefix. You're correct, this does not work. However, I thought about it some more, and I think this is the wrong place to make this change anyway. I don't think we want to say that the function *name* includes the prefix. So instead, I added a function that calculates and returns the identifier, then identified the callers that print the name directly, and made them call the function. This way, also, the python symbol.name and the guile equivalent won't be polluted by the linker namespace. > >> } >> >> /* If we didn't hit the C++ case above, set *funname >> here. */ >> if (funname == NULL) >> - funname.reset (xstrdup (print_name)); >> + funname.reset (xstrdup (print_name.c_str ())); >> } >> else >> { > This 'else' block looks up the funname via lookup_minimal_symbol_by_pc, > but doesn't add the namespace-id. If we had code without debug in a > namespace, I think this is the path it would take, should we not be > displaying the id in this case? > > This might be a good new test to add. Now that print_frame is calling it, instead of find_frame_funname, I don't think the existence of debug symbols no longer matters, so I won't be adding this test case, as it is redundant. v8 should be arriving on the list soon enough -- Cheers, Guinevere Larsen It/she --------------99XuACN6wY9TEhf98FR8KcqX Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit
On 4/20/26 1:28 PM, Andrew Burgess wrote:
@@ -1288,13 +1290,13 @@ find_frame_funname (const frame_info_ptr &frame, enum language *funlang,
 	     stored in the symbol table, but we stored a version
 	     with DMGL_PARAMS turned on, and here we don't want to
 	     display parameters.  So remove the parameters.  */
-	  funname = cp_remove_params (print_name);
+	  funname = cp_remove_params (print_name.c_str ());

Does this work?  The PRINT_NAME will have the namepsace prefix in place,
but doesn't cp_remove_params parse the name as a C++ symbol, so will
this correctly find and remove the parameters?

I haven't looked at the earlier versions, but I have a suspicion that
this might be me causing problems, as I think originally you were adding
the namespace-id as a prefix, and I pushed you to write
print_name_with_namespace.

Anyway, I think you should write a test to cover this case (C++ symbol
in a namespace) and see if this works, if not, then you might need to go
back to something more like your original approach, adding the namespace
prefix.

You're correct, this does not work. However, I thought about it some more, and I think this is the wrong place to make this change anyway. I don't think we want to say that the function *name* includes the prefix.

So instead, I added a function that calculates and returns the identifier, then identified the callers that print the name directly, and made them call the function. This way, also, the python symbol.name and the guile equivalent won't be polluted by the linker namespace.



 	}
 
       /* If we didn't hit the C++ case above, set *funname
 	 here.  */
       if (funname == NULL)
-	funname.reset (xstrdup (print_name));
+	funname.reset (xstrdup (print_name.c_str ()));
     }
   else
     {

This 'else' block looks up the funname via lookup_minimal_symbol_by_pc,
but doesn't add the namespace-id.  If we had code without debug in a
namespace, I think this is the path it would take, should we not be
displaying the id in this case?

This might be a good new test to add.

Now that print_frame is calling it, instead of find_frame_funname, I don't think the existence of debug symbols no longer matters, so I won't be adding this test case, as it is redundant. v8 should be arriving on the list soon enough

-- 
Cheers,
Guinevere Larsen
It/she
--------------99XuACN6wY9TEhf98FR8KcqX--