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

Metzger, Markus T
2025-07-22T07:08:57Z

>> @@ -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/#rc0d0f322c8b484e
>cb620ec3d0d6263190e323182
>
>But I wonder if it is still relevant today...

Hello Simon,

This concept of the debug object moving is much older. See for example:

commit 60d09f0a0d8000359b8f1dd14b51e7f013ea9e5c
Author: Markus Metzger <markus.t.metzger@intel.com>
Date: Fri Mar 11 06:46:15 2022 +0100

gdb, solib-svr4: remove locate_base()

Whenever we call locate_base(), we clear info->debug_base directly before
the call. Thus, we never cache the base location as locate_base() had
intended.

Move the svr4_have_link_map_offsets() check into elf_locate_base(), inline
locate_base() at all call sites, and remove it.

This patch removes some caching of the debug base that had been intentionally
disabled on every call to locate_base(), which was supposed to find the debug
object once and then cache its address for further use.

A typical hunk in this patch is:

@@ -1839,8 +1799,8 @@ svr4_handle_solib_event (void)
return;

/* Always locate the debug struct, in case it moved. */
- info->debug_base = 0;
- if (locate_base (info) == 0)
+ info->debug_base = elf_locate_base ();
+ if (info->debug_base == 0)
{
/* It's possible for the reloc_complete probe to be triggered before
the linker has set the DT_DEBUG pointer (for example, when the

Maybe H.J. has more information on this; a concrete example, maybe?

Regards,
Markus.
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva