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

Kevin Buettner via Gdb-patches
2022-07-16T00:05:20Z

Hi Markus,

On Fri, 15 Jul 2022 10:30:42 +0000
"Metzger, Markus T" <markus.t.metzger@intel.com> wrote:

> 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

Yep.

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

To be clear, I think this patch is okay, but someone who knows about
this area may want to take a look. If no one steps up, I think it
should go in.

>
> Not reviewed:
> > gdb, testsuite: extend gdb_test_multiple checks

I asked a question about this one. Basically, I'd like to understand
the circumstances which led you to making these changes.

> > gdb, python: use gdbarch_iterate_over_objfiles_in_search_order

I okayed this one.

> > gdb, ada: collect standard exceptions in all objfiles

That one looked reasonable to me, but an Ada expert may want to
take a look.

> > gdb, cp: update add_symbol_overload_list_qualified

I said, "LGTM", which is basically an "okay".

> > gdb: update gnu ifunc resolve

I okayed this one.

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

I'd like to see this work go in. So long as it doesn't break existing
(non-linker namespace) use cases, I'm okay with fixing the other
problems later on.

Kevin