Bug 11839 - gdb does not detect calls to dlmopen
Summary: gdb does not detect calls to dlmopen
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: gdb (show other bugs)
Version: 7.2
: P2 normal
Target Milestone: 13.1
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-25 12:23 UTC by mathieu lacage
Modified: 2022-10-24 02:53 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed: 2013-09-19 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description mathieu lacage 2010-07-25 12:23:42 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.
Comment 1 Gary Benson 2011-05-17 13:18:21 UTC
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.
Comment 2 Gary Benson 2011-06-07 15:20:52 UTC
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.
Comment 3 Carlos O'Donell 2013-03-15 04:19:15 UTC
Just ran into this very issue while debugging BZ#15271.

I look forward to having this fixed one day.
Comment 4 Pedro Alves 2013-03-15 10:09:53 UTC
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
Comment 5 Gary Benson 2013-09-19 15:02:57 UTC
I have filed bug 15971 to track the glibc side of this.  Please add yourselves to that bug's Cc list if you require.
Comment 6 Paul Pluzhnikov 2021-11-20 15:53:07 UTC
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.
Comment 7 cvs-commit@gcc.gnu.org 2022-10-18 13:24:54 UTC
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>
Comment 8 Tom Tromey 2022-10-24 02:53:07 UTC
Fix landed.