Bug 11839

Confirmed (building on the testcase of bug 2328):

$ cat my_lib.c
#include <stdio.h>

int
sub1(int x)
{
        printf("sub1 %d\n", x);
}
$ cat my_main_dlmopen.c
#define _GNU_SOURCE
#include <dlfcn.h>

int
main()
{
	void *handle = dlmopen(LM_ID_NEWLM, "./my_lib.so", RTLD_LAZY);
        void (*sub1)(int) = (void (*)(int))dlsym(handle, "sub1");
        sub1(6);
        return 0;
}
$ gcc -o my_lib.so -shared -fPIC -g my_lib.c
$ gcc -o my_main_dlmopen -g my_main_dlmopen.c -ldl
$ gdb my_main_dlmopen
GNU gdb (GDB) Fedora (7.2-51.fc14)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/gary/work/archer/my_main_dlmopen...done.
(gdb) set stop-on-solib-events 1
(gdb) r
Starting program: /home/gary/work/archer/my_main_dlmopen 
Stopped due to shared library event
(gdb) info sh
From                To                  Syms Read   Shared Object Library
0x0000003eac600b20  0x0000003eac618c46  Yes         /lib64/ld-linux-x86-64.so.2
(gdb) c
Continuing.
Stopped due to shared library event
(gdb) info sh
From                To                  Syms Read   Shared Object Library
0x0000003eac600b20  0x0000003eac618c46  Yes         /lib64/ld-linux-x86-64.so.2
0x0000003ead600de0  0x0000003ead601988  Yes         /lib64/libdl.so.2
0x0000003eace1eba0  0x0000003eacf45f5c  Yes         /lib64/libc.so.6
(gdb) c
Continuing.
Stopped due to shared library event
(gdb) info sh
From                To                  Syms Read   Shared Object Library
0x0000003eac600b20  0x0000003eac618c46  Yes         /lib64/ld-linux-x86-64.so.2
0x0000003ead600de0  0x0000003ead601988  Yes         /lib64/libdl.so.2
0x0000003eace1eba0  0x0000003eacf45f5c  Yes         /lib64/libc.so.6
(gdb) c
Continuing.
Stopped due to shared library event
(gdb) info sh
From                To                  Syms Read   Shared Object Library
0x0000003eac600b20  0x0000003eac618c46  Yes         /lib64/ld-linux-x86-64.so.2
0x0000003ead600de0  0x0000003ead601988  Yes         /lib64/libdl.so.2
0x0000003eace1eba0  0x0000003eacf45f5c  Yes         /lib64/libc.so.6
(gdb) c
Continuing.
sub1 6

Program exited normally.

I have been working on an improved linker-debugger interface to address this
and other issues.  Please see these two threads for details:

  http://sourceware.org/ml/archer/2011-q2/msg00000.html
  http://sourceware.org/ml/archer/2011-q2/msg00015.html

I have not written any specific dlmopen-tracking code on the gdb side, but the proposed new interface exposes the information you would require to do this via SystemTap probes.

Just ran into this very issue while debugging BZ#15271.

I look forward to having this fixed one day.

Lots of discussion happened on the libc-alpha (glibc) mailing list, around
2012-Dec - 2013-Jan.

The archives are silly and don't cross through month boundaries; for the whole discussion start here:

  http://sourceware.org/ml/libc-alpha/2012-12/
  http://sourceware.org/ml/libc-alpha/2013-01/

and look for messages with subject "dlmopen and core dumps".

Started around here:

  http://sourceware.org/ml/libc-alpha/2012-12/msg00268.html

I have filed bug 15971 to track the glibc side of this.  Please add yourselves to that bug's Cc list if you require.

I just spent a few hours debugging dlmopen issue, and having to manually add the missing symbols on rerun gets annoying pretty fast.

The GLIBC bug 15971 has been fixed for GLIBC-2.35, now the ball is in GDB's court.

The master branch has been updated by Markus Metzger <mmetzger@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8d56636a0ecbe6c38bf52b0683326ee21693c548

commit 8d56636a0ecbe6c38bf52b0683326ee21693c548
Author: Markus Metzger <markus.t.metzger@intel.com>
Date:   Mon Oct 4 10:24:35 2021 +0200

    gdb, gdbserver: support dlmopen()
    
    In glibc, the r_debug structure contains (amongst others) the following
    fields:
    
      int r_version:
        Version number for this protocol.  It should be greater than 0.
    
    If r_version is 2, struct r_debug is extended to struct r_debug_extended
    with one additional field:
    
      struct r_debug_extended *r_next;
        Link to the next r_debug_extended structure.  Each r_debug_extended
        structure represents a different namespace.  The first r_debug_extended
        structure is for the default namespace.
    
    1. Change solib_svr4_r_map argument to take the debug base.
    2. Add solib_svr4_r_next to find the link map in the next namespace from
    the r_next field.
    3. Update svr4_current_sos_direct to get the link map in the next namespace
    from the r_next field.
    4. Don't check shared libraries in other namespaces when updating shared
    libraries in a new namespace.
    5. Update svr4_same to check the load offset in addition to the name
    6. Update svr4_default_sos to also set l_addr_inferior
    7. Change the flat solib_list into a per-namespace list using the
    namespace's r_debug address to identify the namespace.
    
    Add gdb.base/dlmopen.exp to test this.
    
    To remain backwards compatible with older gdbserver, we reserve the
    namespace zero for a flat list of solibs from all namespaces.  Subsequent
    patches will extend RSP to allow listing libraries grouped by namespace.
    
    This fixes PR 11839.
    
    Co-authored-by: Lu, Hongjiu  <hongjiu.lu@intel.com>

Fix landed.