RE: [PATCH v5 00/15] basic linker namespace support

Metzger, Markus T via Gdb-patches
2022-07-15T10:31:12Z

Hello,

Reviews have slowed down. Here's the current status:

OK'ed by Kevin:
> gdb, solib-svr4: remove locate_base()
> gdb, gdbserver: support dlmopen()
> gdbserver: move main_lm handling into caller
> gdb, gdbserver: extend RSP to support namespaces
> gdb, compile: unlink objfile stored in module
> gdb, ada: update ada_lookup_simple_minsym
> gdb, hppa: remove unused hppa_lookup_stub_minimal_symbol
> gdb, symtab: inline find_quick_global_symbol_language
> gdb, solib-svr4: support namespaces in DSO iteration

Reviewed by Kevin but asking for another reviewer:
> gdb, ada: update ada_add_all_symbols

Not reviewed:
> gdb, testsuite: extend gdb_test_multiple checks
> gdb, python: use gdbarch_iterate_over_objfiles_in_search_order
> gdb, ada: collect standard exceptions in all objfiles
> gdb, cp: update add_symbol_overload_list_qualified
> gdb: update gnu ifunc resolve

Another question is what to do about those known issues:

> - get_symbol_address() and get_msymbol_address() search objfiles for a
> 'better' match. This was introduced by
>
> 4b610737f02 Handle copy relocations
>
> to handle copy relocations but it now causes a wrong address to be
> read after symbol lookup actually found the correct symbol. This can
> be seen, for example, with gdb.base/dlmopen.exp when compiled with
> clang.
>
> - gnu ifuncs are only looked up in the initial namespace.
>
> - lookup_minimal_symbol() and lookup_minimal_symbol_text() directly
> iterate over objfiles and are not aware of linker namespaces.

Can they be accepted and addressed one-by-one? Or would they all need
to be addressed before the series can be merged? I had to adjust two expected
outputs but otherwise, tests pass on x86-64. We know that namespace
support is incomplete, though.

For get_symbol_address() and get_msymbol_address() I believe we need
to remove the objfiles iteration and trust that the symbol is the right one
and just return its value. That means we need to find another way to
handle copy relocations. I was hoping that someone could help with that.

regards,
markus.