If you have a program that calls dlmopen (LM_ID_NEWLM), gdb will never see the binary in its link map. This is not very surprising because the link map of the inferior as reported by the libc does not contain the newly-loaded binary. Instead, it is stored in a separate linkmap for the new namespace which gdb never goes to look in. The proper way to deal with this would be probably to try to support the solaris librtld_db.so interface in the libc and then make gdb use it to read the inferior's link map.
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.