Re: [PATCH v4] gdb, gdbserver: support dlmopen()

[Ben Woodard <woodard@redhat.com>]

> On May 31, 2022, at 2:29 AM, Metzger, Markus T <markus.t.metzger@intel.com> wrote:
> 
> Thanks Kevin and Ben, for your positive feedback on the usefulness of this.
> 
> The patch has grown into a small series when I added gdbserver support
> and changed several occurrences of direct objfiles traversal with calls to
> gdbarch_iterate_over_objfiles_in_search_order() to take namespaces into
> account.
> 
> The latest version can be found in users/mmetzger/dlmopen.  I'll also send
> it as v5 with a few opens left.
> 
>> While I'm convinced that other work will be needed to improve GDB's UI
>> to both display linker namespaces (e.g.  in the "info shared" command)
>> and accept namespace qualifiers when specifying a symbol (e.g. with a
>> breakpoint command), I think that this current patch is useful as
>> is.  I.e., I'd like to see it (or a modest update) go in as soon as
>> possible.
> 
> Indeed, there are a few known issues and many direct objfiles traversals
> in GDB that all assume that there can be at most one global symbol
> of the same name.  Fixing all of them will be a fair amount of work.
> 
> Ben Woodard:
>> How do I specify the filename.c TU which is part of the libstdc++.so which is
>> linked into one of the audit libraries rather than the one that is linked into the
>> app. Path to the filename isn't sufficient because they could have both been built
>> in the same directory structure from different sources. That is why I believe that
>> we need some way to know which shared objects are in which namespace and
>> some way to specify which linkage namespace to search.
>> 
>> Since the linkage namespaces are on a linked list in glibc, I thought referring to
>> the default namespace as 0 and counting the depth and then reusing the C++
>> namespace qualifier might be a good idea but it is not something that I am hung
>> up on. If someone has a better idea, great.
> 
> I currently keep namespaces hidden and local to SVr4.  The rest of GDB doesn't
> know about them.
> 
> The official namespace id that dlinfo(RTLD_DI_LMID) provides is available for
> dynamic linker notifications but not during the (initial) load map scan - or I
> haven't found it.  I use the address of the r_debug(_ext) object as identifier.
> 

To me this sounds like a weakness in the r_debug interface that glibc provides, shall we bring this up to with the glibc folk?
Sure they would have to bump it up to version 3 but, I do not think any Unix has been here before and we are probably running into issues that no one has had to consider before.

I think that you could probably explain the issue on glibc-alpha better than I can but I can take that on if it would help advance the topic.

> We could simply number them, as Ben suggests, using the ordinal in the
> r_debug chain.  This may be confusing to users who are aware of the actual
> namespace id, though.
> 

I think using the namespace ID is a better idea than my ordinal numbering system. Mostly, I just felt GDB some sort of handle to disambiguate symbols that exist in different namespaces.

> To make GDB aware of namespaces, we'd probably want to partition
> solibs and objfiles by namespace.  This will be a big patch when we change
> program_space::objfiles() to take a namespace id argument and update all
> users.
> 
> Ideally, I think we'd want objfiles to be shared so we only read the debug
> info once per unique instance and relocate it lazily but GDB is currently not
> doing that and it doesn't sound entirely trivial.

Yeah with DWARF being what it is, you really do not want to blow up the memory utilization unnecessarily. However, I think increased memory utilization by debuggers is preferable to not being able to debug audiors effectively.  I am not intimately aware of GDB’s internals but I can imagine a lot of data structures having to change to go from a symbol pointing to one address in one loaded object to a symbol referring to a set of objects and addresses. That doesn’t sound trivial.

-ben

> 
> regards,
> markus.
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>