From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id kWuAKSvznGg3twIAWB0awg (envelope-from ) for ; Wed, 13 Aug 2025 16:18:51 -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=G/ZOGBMa; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id A61011E0B3; Wed, 13 Aug 2025 16:18:51 -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 server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (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 C3F111E087 for ; Wed, 13 Aug 2025 16:18:50 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5419C3858CD1 for ; Wed, 13 Aug 2025 20:18:50 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5419C3858CD1 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=G/ZOGBMa 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 5C5843858D20 for ; Wed, 13 Aug 2025 20:18:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5C5843858D20 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 5C5843858D20 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1755116289; cv=none; b=Gc2x8c4ctVGPzZyR+/lXqRWKMiEUhkz1zBRayB9TKkxMyYhyPngEaRmeLuNM3zVhjyZDJ3GbJNeCEnjutqJzSQqxtPHf2svumij6bAspJPjtRZOiSLk6AZmV+SkPsj5NrPaqaOCg+689QZWf3bvXUtdkH5Mk/aE5HfM35cck+9U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1755116289; c=relaxed/simple; bh=F3VnXRhPAdhOtfxwy5/jgAi75tvgK8AmZZm0kx9astQ=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=ODj+XG1t3x9AGpF9GDeeaGPydXyMZXrP0HEUT2AtmsGri+mihjdBamMR9cV8OFBnKTuBWCSlL+AyPklI7nzw8NCWvkcAUx1rWndujSZJMnv5Lc1uB9tAJXBpDnnwEK0atvh1P7C8Zt1l63hSYcGQewI3YjP7qJLdjhC1qcagijM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C5843858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1755116289; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=LgcvxQbAcrl/jcKdQoJLXt6vOR1r6z1U0mlW7HF+xxs=; b=G/ZOGBMaXFtWFza5puD3ano3LAcjUba5nJJWSrROGdsrjBoD2/42SoqY1NjqU3DvK6vb4t bIz4xPGvBOsEjTgntSkY7O0brSE39spmt2R+7rqYmImJCz5mG6xise9Zrv166YVJ1JAZ66 T0qopZS4By7mJSRVdsLn52Y8GMxpOQU= Received: from mail-pj1-f69.google.com (mail-pj1-f69.google.com [209.85.216.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-52-41mK0OK_MIWSdOvqEBp4Sg-1; Wed, 13 Aug 2025 16:18:07 -0400 X-MC-Unique: 41mK0OK_MIWSdOvqEBp4Sg-1 X-Mimecast-MFC-AGG-ID: 41mK0OK_MIWSdOvqEBp4Sg_1755116287 Received: by mail-pj1-f69.google.com with SMTP id 98e67ed59e1d1-32326e72dfbso467581a91.3 for ; Wed, 13 Aug 2025 13:18:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755116286; x=1755721086; h=content-transfer-encoding:in-reply-to:content-language:from :references:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=LgcvxQbAcrl/jcKdQoJLXt6vOR1r6z1U0mlW7HF+xxs=; b=L2zdDapUmwRa20io8wIwluboPL/hFQEeTRJUBD5KMaRrrW0AYfeYaxeWFwAy7tfRyB Sl/rYVI7i3hx7Rh9yyN2Fa0b7T0yTboC7XUnURjDg/KtkX+5ANRhST3OIp7sSNw7ZIpA Q59NLHdQRS20R8xrCyQK2mbDOa+2k2L+AXoydGRcEgzjZYMcQzd5rcPJ1X047kWVEB/i XsDe11ET5PbFs2MYolzW83XAKeB2hIKhh75Z5kFSPkrR5euj5QX5NKQMhOx/+3oMD/AA smI7fc5vgoZH8aJs2mYLJhJ5MEPHOiwLHyzzAsX5JjnHAvgf+9KBxWxqC8qPKq2bFcb7 npUA== X-Forwarded-Encrypted: i=1; AJvYcCVZe4c8ZEO8X2Myq77p5yC+3IX71knvY7fe1kRJo18ZqyIdDSVwY6BH34JjJcgo3h79KF4KeaQkYqSKZA==@sourceware.org X-Gm-Message-State: AOJu0Ywu0ud/5o3umR6c7EhC44wOvHyBNkw07LIG/Zo7PTY6DsRhsc05 WkqHdj6kA88i/nKqMih/IJfGPHGy/Z39Ra249Y7Qlem65lRtMwVIrEGSK2NTwlF9wRUm2131dih 27AKE5HmnoOBUEY25rylxyEpQY1qytuFmDxpUI9vZHz/aqW4cz7Uk+PDZLYsmBkREtKDw6go= X-Gm-Gg: ASbGnctYxF2QIm5+Yv7aCfaWJkmKj7FtgcPyv+wHTNYaHKYeHd+l6JzoPMip7TxXwzj 110d0Dz/tJMDAbLTGj3SFwwxVvgjS5l1NN9Yjs/ntJpb/SE5skS8ZDYC2Ub27SzmNYvYWa07oz8 bG+eGh43yrARvBw4c/XjWvFyG8SESEpF3k245NSRK5J/Z89hHmru5az5o5bCOHRMk7hE9mjt+Qr cj+kgoju8cDcpUdu1hqFqJON5WvW3ucP8DOk/UHQU6/aZwfGnn665VnV442ubu95rcI60eIb76c tl313xDSW+cy+0mOqAd1Ikll0CxSlPUwXZNzUt1EFa2woWBYBe0= X-Received: by 2002:a17:90b:5627:b0:31f:b51:eef9 with SMTP id 98e67ed59e1d1-32327c87748mr841233a91.17.1755116286415; Wed, 13 Aug 2025 13:18:06 -0700 (PDT) X-Google-Smtp-Source: AGHT+IEFA31ls+U9HuM7cjCe3cPOD7Kokw5KS5avuYdtOcgt7130sgfkpyERQ6DUnWXgioLPcXrIRw== X-Received: by 2002:a17:90b:5627:b0:31f:b51:eef9 with SMTP id 98e67ed59e1d1-32327c87748mr841207a91.17.1755116285930; Wed, 13 Aug 2025 13:18:05 -0700 (PDT) Received: from ?IPV6:2804:14d:8084:9a69::1000? ([2804:14d:8084:9a69::1000]) by smtp.gmail.com with ESMTPSA id 98e67ed59e1d1-323257e0b11sm892871a91.34.2025.08.13.13.18.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Aug 2025 13:18:05 -0700 (PDT) Message-ID: <9a279d00-51b1-40c3-94c6-90b6ffac9a8e@redhat.com> Date: Wed, 13 Aug 2025 17:18:03 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/1] gdb: Print linker namespace when showing a frame To: Simon Marchi , gdb-patches@sourceware.org References: <20250812202142.3308633-1-guinevere@redhat.com> <2cad9291-cebd-4074-a131-841248344fe3@simark.ca> From: Guinevere Larsen In-Reply-To: <2cad9291-cebd-4074-a131-841248344fe3@simark.ca> X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: jo8nvSJQqwpGrTny4h4KeVAn5VW2_EC9RB36PL0sTJY_1755116287 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed 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 8/13/25 4:28 PM, Simon Marchi wrote: > > On 2025-08-12 16:21, Guinevere Larsen wrote: >> When a user is stopped in a private linker namespace, the only way for >> them to realize that is using the _linker_namespace convenience >> variable. While serviceable, this is a sub-optimal solution, as most >> users are unaware of convenience variables. >> >> This commit introduces a new way for users to be informed of the linker >> namespace of a function, by printing it along with the function name. >> This is done by using the proposed syntax for symbols and locations, >> like so: >> >> #0 [[0]]::main () >> >> This is done by exporting part of the functionality behind the >> _linker_namespace variable, namely, find the linker namespace that >> contains the given address on the current program space. Since this >> change also touched the convenience variable code, this commit fixes a >> formatting error in that function. >> >> The namespace ID is only printed if multiple namespaces are active, >> otherwise no change in behavior is expected. This commit also updates >> the test gdb.base/dlmopen-ns-ids.exp to test this functionality. > Just bear in mind that an address could be in a library that is part of > multiple namespaces. The only real occurence I know of today is the > dynamic linker itself. If you're stopped inside the dynamic linker, > with this patch, I think we would end up showing one arbitrary > namespace id. > > The idea of sharing libraries between namespaces was also pitched in the > past, although it wasn't merged: > > https://sourceware.org/pipermail/libc-alpha/2021-October/131818.html > > I guess the right behavior would be to not show a namespace ID if the > piece of code is globally present in all namespaces, or show a list of > namespace IDs if the piece of code is visible in only some namespaces. > Perhaps it's not worth finding a solution for this right now, but I > thought I'd mention it so that we are aware of the limitations. Yeah, I don't think it would be too hard to solve this problem, but considering that only the linker namespace can do it for now, I don't think it's worth implementing a solution. > >> --- >> gdb/solib.c | 28 ++++++++++++++--------- >> gdb/solib.h | 5 ++++ >> gdb/stack.c | 13 +++++++++++ >> gdb/testsuite/gdb.base/dlmopen-ns-ids.exp | 12 +++++++++- >> gdb/testsuite/gdb.mi/mi-dlmopen.exp | 2 +- >> 5 files changed, 47 insertions(+), 13 deletions(-) >> >> diff --git a/gdb/solib.c b/gdb/solib.c >> index 3ec2032f012..2f32f08b645 100644 >> --- a/gdb/solib.c >> +++ b/gdb/solib.c >> @@ -1805,6 +1805,21 @@ remove_user_added_objfile (struct objfile *objfile) >> } >> } >> >> +/* See solib.h. */ >> + >> +int >> +linker_namespace_contains_addr (CORE_ADDR addr) > This function name makes it sound like it's a function to check whether > a given namespace contains a given address. I would suggest > "linker_namespace_for_addr" or something like that. I couldn't think of a better name, thank you! >> +{ >> + for (const solib &so : current_program_space->solibs ()) >> + if (solib_contains_address_p (so, addr)) >> + { >> + if (so.ops ().supports_namespaces ()) >> + return so.ops ().find_solib_ns (so); >> + } > Please combine the two ifs: > > for (const solib &so : current_program_space->solibs ()) > if (solib_contains_address_p (so, addr) > && so.ops ().supports_namespaces ()) > return so.ops ().find_solib_ns (so); fixed >> diff --git a/gdb/solib.h b/gdb/solib.h >> index b9465e103bd..213f66c7ae4 100644 >> --- a/gdb/solib.h >> +++ b/gdb/solib.h >> @@ -303,6 +303,11 @@ extern const char *solib_name_from_address (struct program_space *, CORE_ADDR); >> >> extern bool solib_contains_address_p (const solib &, CORE_ADDR); >> >> +/* Given the address ADDR, return which linker namespace contains >> + this address in the current program space. */ >> + >> +int linker_namespace_contains_addr (CORE_ADDR addr); > If nothing in the call tree relies on the current program space, I would > prefer if the program space was passed as a parameter. sure > >> + >> /* Return whether the data starting at VADDR, size SIZE, must be kept >> in a core file for shared libraries loaded before "gcore" is used >> to be handled correctly when the core file is loaded. This only >> diff --git a/gdb/stack.c b/gdb/stack.c >> index e6335669531..10078e06766 100644 >> --- a/gdb/stack.c >> +++ b/gdb/stack.c >> @@ -1363,6 +1363,19 @@ print_frame (struct ui_out *uiout, >> annotate_frame_function_name (); >> >> string_file stb; >> + >> + /* Print the linker namespace containing the frame, if there >> + are multiple namespaces active. */ >> + LONGEST num_linker_namespaces; >> + get_internalvar_integer (lookup_internalvar ("_active_linker_namespaces"), >> + &num_linker_namespaces); > I would really prefer some direct (C++) function call, instead of going > through the internalval mechanism. It makes it much easier to navigate > the code, find references, etc. Sure, makes sense. > > And because I looked at _active_linker_namespaces, I have some thoughts > about that. It's not related to this patch, but should perhaps be > addressed before the release. > > First, the name "_active_linker_namespaces" insinuates that it contains > something like a list of all the active linker namespaces. It should > perhaps be "_active_linker_namespaces_count" or > "_num_active_linker_namespaces"? We already have > $_inferior_thread_count, so I guess _active_linker_namespaces_count > would be good for consistency. Well, since we only ever keep track of active namespaces, we could also simplify it to _linker_namespace_count, which follows closer to _inferior_thread_count anyway. > > Then, _active_linker_namespaces is set in > svr4_solib_ops::maybe_add_namespace, which is called when > fetching/updating/listing shared libraries. That doesn't work well with > multi-inferior for instance. Imagine you stop at a breakpoint in > inferior 1, which has 2 namespaces, _active_linker_namespaces is set to > 2. Then you run inferior 2, which has 2 namespaces, stop at a > breakpoint, _active_linker_namespaces is set to 3. If you focus back to > inferior 1, _active_linker_namespaces will still have the value for > inferior 2. My feeling is that the variable should be sensitive to the > user's focus. That would probably mean calling > solib_ops::num_active_namespaces on the current program space's > solib_ops. You're right, I didn't think about the multi-inferior case. But I'm not sure if the answer should be in solib_ops or in the inferior. With that, svr4_solib_ops::maybe_add_namespace updated a value held by the inferior, and when you had multiple solib_ops in one inferior, the addition of the rocm solib_ops could also increment the count of namespaces. This would also solve the problem below, while leaking minimal solib information to inferior. What do you think? -- Cheers, Guinevere Larsen She/it > > And then, since we're talking about that, I was wondering how to handle > _active_linker_namespaces in my "multiple solib ops" series. Imagine > you have a program space with one svr4_solib_ops and one rocm_solib_ops, > which is how I envision it will work with my patch, when debugging a > ROCm program. How would I implement _active_linker_namespaces then > (assuming you first made the change described above). Should I iterate > on all the solib_ops of the program space and sum up their > solib_ops::num_active_namespaces? In a normal scenario, that would give > me 2, which is kinda right because the linker namespace on the host side > is distinct from the linker namespace on the device side, so you > effectively have 2 of them in the program space. But is it going to > work with the uses this convenience variable is intended for? I don't > really what the intended uses are. > > Simon >