Re: [PATCH 11/11] gdb: multiple solib_ops per program space

[Simon Marchi <simon.marchi@polymtl.ca>]

On 4/28/26 1:27 PM, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simon.marchi@efficios.com> writes:
> 
> Simon> This patch adds the possibility for a program space to have multiple
> Simon> solib_ops.  The motivation for this is to support ROCm (GPU) debugging
> Simon> more cleanly.
> 
> Simon> Currently, when debugging a ROCm program, in order to be able to list
> Simon> device code objects (the equivalent of shared libraries but for the
> Simon> GPU), we install an instance of rocm_solib_ops as the program space's
> Simon> sole solib_ops.  But in order to still be able to list host shared
> Simon> libraries, the rocm_solib_ops wraps the previously installed solib_ops
> Simon> (currently always an svr4_solib_ops instance) and forwards method calls
> Simon> to it.
> 
> From this description and the comment in progspace.h, I wonder if this
> is a case where an inferior should have multiple program spaces.

I never thought about that.

The host and device do share a single virtual address space.  This
doesn't mean that both host and device can necessarily access each
other's memory transparently, but the host stuff and the device stuff
won't overlap.  So perhaps that could indeed be modeled by one struct
address_space bound to two struct program_space.  I'll discuss that with
my team.

> However I don't really want to block the work that's already been done.

Going to multiple solib ops is a big design change, so it if turns out
that it's not the right one, it's better to know now.

> Simon>  struct solib_ops
> Simon>  {
> Simon> -  explicit solib_ops (program_space *pspace)
> Simon> -    : m_pspace (pspace)
> Simon> +  explicit solib_ops (program_space *pspace, bool handle_main_objfile)
> Simon> +    : m_pspace (pspace), m_handle_main_objfile (handle_main_objfile)
> 
> No need for 'explicit' any more.

Ack.

Simon