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

["Metzger, Markus T via Gdb-patches" <gdb-patches@sourceware.org>]

Hello,

>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.

I eventually found the root cause of this.  When looking up the symbol, GDB
finds the correct symbol in the correct objfile in the correct linker namespace.

Instead of taking the value directly from the symbol, though, get_symbol_address()
iterates over all objfiles again and looks for a matching minimal symbol.  This time,
however, it does not use iterate_over_objfiles_in_search_order() so it does not
take linker namespaces into account and it may hence find a different instance
of that symbol in a different objfile in a different linker namespace.

This was introduced in

    4b610737f02 Handle copy relocations

The commit message says that this is to handle copies inside the main program.
Wouldn't it suffice to look inside the main objfile in that case, rather than inside
each objfile?  This would also be a lot faster.

Alternatively, it would need to use iterate_over_objfiles_in_search_order().  That
would be still slow, however, assuming we don't run into issues with recursive calls.

Could copy relocations be handled when processing a shared library's symbols so
get_symbol_address() and get_msymbol_address() can just return the address
stored inside the respective symbol object?

I counted 123 other places that iterate over objfiles in a flat list.  I hope they don't
try to lookup symbols...

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