Sources Bugzilla – Bug 11839
gdb does not detect calls to dlmopen
Last modified: 2013-03-15 10:09:53 UTC
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