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

["Metzger, Markus T" <markus.t.metzger@intel.com>]

>> @@ -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
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928