Re: [PATCH v3 09/44] gdb, gdbserver, ze: in-memory libraries

[Simon Marchi <simark@simark.ca>]

On 12/15/25 8:07 AM, Metzger, Markus T wrote:
>> Would it work to just make gdbserver return these in-memory-library
>> elements, without even a qSupported flag?  Would older GDBs just ignore
>> them?
> 
> GDB silently ignores unknown elements and unknown attributes.
> 
> I will drop most of this patch and just send the new in-memory-library
> response without opt-in and without fallback.

Ack, glad to know it works.

>> Ok, so "info shared" shows solib->name.  For in-memory solibs, you don't
>> set solib->name?  Does this mean that no name is shown in "info shared"
>> for these libraries?
> 
> No, 'info shared' prints the name given by
> 
>   /* Constructor.  BASE and SIZE define where the BFD can be found in
>      target memory.  */
>   target_buffer (CORE_ADDR base, ULONGEST size)
>     : m_base (base),
>       m_size (size),
>       m_filename (xstrprintf ("<in-memory@%s-%s>",
> 			      core_addr_to_string_nz (m_base),
> 			      core_addr_to_string_nz (m_base + m_size)))
> 
> This is existing code.  I'm no longer setting solib->name for in-memory libs.

Ok, I am a bit confused, because I see that we pass a "name" at the
constructor of struct solib, but then solib_map_sections does:

  so.name = bfd_get_filename (so.abfd.get ());

I guess these is how target_buffer::m_filename ends up as the solib
name.

>> As of today, even with this change, solib-rocm.c could set solib->name
>> to whatever it wants.  If we ever want to support remote debugging with
>> ROCm, we would want to find a way to get our `memory://...` string as
>> the name.
>>
>> Do you think that the remote side could provide a name inside an
>> <in-memory-library> element?  A ROCm would put that `memory://...`
>> string.  But in general, it would be a place to put a user-friendly name
>> that will end up in "info shared".
> 
> We'd need to route that through.  I have not looked into it.  I'm quite happy
> with the name GDB chooses.  It makes it easy to copy&paste to a 'dump
> memory' command.

For ROCm, I think we'd really want to keep that syntax, because it's
used and understood by other tools in the ecosystem.  As long as there
is a backwards-compatible way to implement it in the future, I am happy.

>>>>> +      if (so.end <= so.begin)
>>>>> +	error (_("Bad address range [%s; %s) for in-memory shared library."),
>>>>> +	       core_addr_to_string_nz (so.begin),
>>>>> +	       core_addr_to_string_nz (so.end));
>>>>
>>>> Sounds like we should never end up with an solib like this, I don't
>>>> think we need to handle this case here.
>>>
>>> We're subtracting so.begin from so.end.  If you don't like the error, we
>>> should assert this.  The only place that currently adds such solibs ignores
>>> those with a warning, so asserting it should be fine.
>>
>> Yes I think an assert makes sense here (or in an eventual solib
>> constructor that takes these two addresses).  Filtering for bad solib
>> data would always be done earlier than that.
> 
> I'd leave the assert here.  This is where we need that property asserted.

Assert yes, not error().

Simon