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:
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.
I acknowledge that glibc needs to do something about this.
(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).