This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug dynamic-link/15971] New: No interface for debugger access to libraries loaded with dlmopen
- From: "gbenson at redhat dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 19 Sep 2013 15:00:22 +0000
- Subject: [Bug dynamic-link/15971] New: No interface for debugger access to libraries loaded with dlmopen
- Auto-submitted: auto-generated
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.