Re: [PATCH v5 03/15] gdb, gdbserver: support dlmopen()

Simon Marchi
2025-07-21T20:41:49Z

On 6/2/22 9:25 AM, Markus Metzger via Gdb-patches wrote:
> @@ -359,14 +370,35 @@ struct svr4_info
> probe_and_action->prob->address. */
> htab_up probes_table;
>
> - /* List of objects loaded into the inferior, used by the probes-
> - based interface. */
> - struct so_list *solib_list = nullptr;
> + /* List of objects loaded into the inferior per namespace, used by the
> + probes-based interface.
> +
> + The namespace is represented by the address of its corresponding
> + r_debug[_ext] object. We get the namespace id as agrument to the
> + 'reloc_complete' probe but we don't get it when scanning the load map
> + on attach.
> +
> + The r_debug[_ext] objects may move when ld.so itself moves. In that
> + case, we expect also the global _r_debug to move so we can detect
> + this and reload everything. The r_debug[_ext] objects are not
> + expected to move individually.
> +
> + The special entry zero is reserved for a linear list to support
> + gdbstubs that do not support namespaces. */
> + std::map<CORE_ADDR, so_list *> solib_lists;

Hi Markus (and others),

I'm currently doing some work inside solib-svr4.c, and I am puzzled by
the comments that say that _r_debug and ld.so can move.

I noticed that when starting the inferior, we try to read the shared
library list very early, before the dynamic linker had time to set the
DT_NEEDED slots. So at this point, we read read a debug base of 0. And
so we need to handle it changing from 0 to the value it will eventually
have.

But are there really use cases of ld.so relocating mid-execution? I
would have hoped that when we have a value for the default debug base,
we can assume that it won't change.

The only thing related to the debug base changing I found is this:

https://pi.simark.ca/gdb-patches/20080221014732.GA27568@caradoc.them.org/T/#rc0d0f322c8b484ecb620ec3d0d6263190e323182

But I wonder if it is still relevant today...

Thanks,

Simon