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

[Simon Marchi <simark@simark.ca>]

On 7/22/25 3:07 AM, Metzger, Markus T wrote:
> 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?

Thanks for the pointer to the patch.  I understand how this code was
indeed dead before your patch.  If H.J. knows concrete examples, it
would be very nice.

The 2008 patch from Daniel Jacobowitz I pointed to in my other email
[1], that I think started this pattern, which probably then spread by
copy-paste, was about having a custom dynamic loader interposing itself
between the kernel and the libc dynamic loader:

    They are motivated by a custom dynamic linker I've been working with
    for the last few weeks.  It is an intermediate stage between the
    kernel ELF loader and the C library's normal runtime loader, which
    adjusts a couple of things in the new binary before it starts.  I
    have made it as transparent to the debugger as possible, but there
    are still a few quirks that seem impossible to eliminate (they bump
    up against the userspace/kernelspace security boundary).

My understanding is that his binary was using a custom dynamic loader
(INTERP), which was doing some stuff, then handed control over to the
real libc dynamic loader.

My question is basically: do we need to support this use case?  If this
was to support an experiment that someone was doing 20 years ago and
nothing else, then perhaps we can simplify the code today, which will
then make subsequent changes easier.

Right now I'm leaning towards not having to support that kind of use
case, until proven otherwise.

Simon

[1] https://pi.simark.ca/gdb-patches/20080221014732.GA27568@caradoc.them.org/T/#mb8a42f0b940333583bb4f7fffc3ea71dd75180de