Bug 15971 - No interface for debugger access to libraries loaded with dlmopen
Summary: No interface for debugger access to libraries loaded with dlmopen
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: dynamic-link (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-19 15:00 UTC by Gary Benson
Modified: 2015-10-16 21:40 UTC (History)
9 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Gary Benson 2013-09-19 15:00:22 UTC
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.
Comment 1 Carlos O'Donell 2013-09-19 15:13:21 UTC
I acknowledge that glibc needs to do something about this.
Comment 2 mathieu lacage 2015-02-12 12:38:05 UTC
(In reply to Gary Benson from comment #0)
> glibc has no interface for debuggers to access libraries loaded using
> dlmopen (LM_ID_NEWLM).  This issue was originally filed as GDB bug 11839.

I filed that gdb bug 4 years ago and I just discovered this glibc bug because you added a comment to the gdb bug about this one.

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

Yes, I am one of these people. I also wrote my own loader because I needed more than the 32 namespaces provided by glibc so, it would be really helpful if the solution you choose to implement can be made to work with a dynamic number of namespaces that is potentially larger than 32.

I have not looked at the glibc loader in a long time but if there was progress on this (gdb/glibc interface for namespaces) front, I would probably try to work on a patch for glibc to support dynamically-allocated namespaces.

Regardless of the status of this feature, I would be happy to provide testing help and/or debugging/implementation time once a decision on how to add this feature is made (I read the ML discussions and I would personally favor the dwarf or r_debug solution).