This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug dynamic-link/15971] New: No interface for debugger access to libraries loaded with dlmopen


https://sourceware.org/bugzilla/show_bug.cgi?id=15971

            Bug ID: 15971
           Summary: No interface for debugger access to libraries loaded
                    with dlmopen
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: dynamic-link
          Assignee: unassigned at sourceware dot org
          Reporter: gbenson at redhat dot com

glibc has no interface for debuggers to access libraries loaded using dlmopen
(LM_ID_NEWLM).  This issue was originally filed as GDB bug 11839.

The current rtld-debugger interface is described in the file
elf/rtld-debugger-interface.txt under the "Standard debugger interface"
heading.  This interface only provides access to the first link map
(LM_ID_BASE).  This interface is not obviously extendable for the reasons
described here: http://gbenson.net/?p=407.

The probes-based rtld-debugger interface allows debuggers to see libraries
loaded using dlmopen as they appear.  This is enough to debug applications
started in the debugger, but not enough to attach to a running process or to
debug using a core file.

There was some discussion of this subject on the libc-alpha mailing list
between November 2012 and January 2013.  The archives are not easily navigable,
but the various messages can be found here:

  https://sourceware.org/ml/libc-alpha/2012-11/subjects.html#00656
  https://sourceware.org/ml/libc-alpha/2012-12/subjects.html#00078
  https://sourceware.org/ml/libc-alpha/2013-01/subjects.html#00358

I don't know in detail what the interface should look like, but some points:

1) A Solaris-style librtld_db.so would be undesirable as it would suffer much
the same issues as libthread_db.so.

2) The interface must be usable by gdbserver, so it must be fairly lightweight.
 An interface that required eg a Python interpreter would exclude users running
gdbserver in constrained environments.

3) There are people using GDB to debug applications with 5,000 shared libraries
and more, so performance is an issue.

4) The interface should work without debugging symbols to be useful for tools
such as ABRT.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]