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

["Metzger, Markus T" <markus.t.metzger@intel.com>]

Hello Pedro,

>>> I'm wondering whether ideally symbol lookup would be updated to handle
>>> different namespaces.  I'm thinking of for example
>>> svr4_iterate_over_objfiles_in_search_order.
>>
>> Do you mean that we should restrict the search to the namespace of the
>> current_objfile argument?  And use, say, the default namespace if that is
>nullptr?
>
>Something like that.  I mean, doesn't the dynamic loader restrict resolving
>symbols to
>the same namespace (and then the global namespace, I guess)?  Not sure about
>completely restricting to
>the namespace is what users would want, but at least I'd think we should search
>symbols in the current
>namespace first before searching the global namespace and then other
>namespaces (*).  The idea being that
>evaluating an expression in GDB should yield the same result the same
>expression would yield if coded
>in the program.
>
>(*) Similar to how we search symbols in scope, and can still print static globals of
>other
>files even if they're not in scope.
>
>It's just a question at this point, I haven't thought about actual use cases, but I
>think
>it's worth it to ponder about it.

Indeed.  From what I could find about linker namespaces, symbol lookup is actually
restricted entirely to the namespace.

I extended my test case by adding a dependent DSO that gets loaded
automatically when I dlmopen() the test DSO.  When breaking inside the test
DSO, I change a variable inside the dependent DSO from GDB.  This should
affect the current namespace but not others.  And, since the variable is not
located in the current DSO, GDB would need to traverse that namespace
to find the correct instance.

This appears to be working [1] as long as I stay on the ELF symbol level.
GDB has separate objfile and separate so_list objects for each instance
of a DSO inside a separate namespace.

When I compile the test with clang, however, which does not add a declaration
for the variable inside the test DSO, GDB reads the DWARF of the dependent
DSO, which contains the variable.  It does that several times for different instances.
When looking up the name, GDB uses different objfile objects and finds different
symbol objects, yet it ends up accessing the same target virtual address.

Tom commented on objfile handling and seemed to suggest that GDB would
only have a single object per binary file.  That's not the case but maybe GDB only
keeps a single DWARF instance?  This shouldn't matter since the relocation offsets
are different for the different DSO instances - provided we stored them outside
of the CU objects.  I'm still debugging this.

Regards,
Markus.

[1] I'm currently ignoring things like manually added symbol files.  They are
assumed to be added to the initial namespace.  This won't be easy to extend
since I'm not getting the namespace id when traversing the r_debug chain
(e.g. on a full update) so I'm using the r_debug address to identify namespaces,
but that will not be available to users, which would want to use the namespace
id returned by dlinfo().  A topic for another day.
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