Re: [PATCH 1/1] gdb: Print linker namespace when showing a frame

[Guinevere Larsen <guinevere@redhat.com>]

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
>