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

[Pedro Alves <pedro@palves.net>]

On 2022-03-09 12:24, Metzger, Markus T wrote:
> Hello Pedro,
> 
>> Should the commit have a Co-Authored-By: tag for H.J.?
> 
> Definitely.  I didn't know we were using such tags.
> 
> 
>> 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.

Pedro Alves

> 
> 
>> Can you describe what xml changes were necessary?  Do we need to update
>> the manual where the xml/packet are described?
> 
> This patch doesn't change the XML so everything ends up in a flat list and GDB
> doesn't really know about namespaces.  This prevents incremental updates
> and would also prevent things like the above.
> 
> I had planned to leave support for that for backwards compatibility and update
> the XML to pass namespaces for future versions.  See also
> https://sourceware.org/pipermail/gdb-patches/2022-February/186135.html.
> 
> If we need GDB to know about namespaces, however, this wouldn't work and
> we'd instead need to conditionalize namespace support based on gdbserver
> features.
>