Re: dlmopen and core dumps

[Roland McGrath <roland at hack dot frob dot com>]

> Is that because r_debug->r_map won't contain anything not in the
> initial namespace?

Yes.

> What do core dumps have to do with this? Isn't it the same problem in
> a live process?

As Gary said, the sdt probes recently added give a mechanism for a debugger
to catch loading events in any namespace.  It's not just core dumps that
have the lack, but also attaching to an existing process after a secondary
namespace has already had objects loaded.

> Actually the first question I have is: Is there prior art for this?
> Have you done
> a review of the existing solutions from other unices to see if any of them
> have implemented what we think we need?

AFAIK the only other implementation with dynamic linker namespaces is
Solaris.  Someone should indeed look into what mechanisms they have, sure.
I suspect that the only way is via the librtld_db interface.  See:
	http://docs.oracle.com/cd/E23824_01/html/819-0690/chapter6-1247.html#chapter6-15
(This is an analogue to libthread_db, for getting at dynamic linker
internals rather than pthreads internals.)  That sounds like a nice idea,
but we know from libthread_db that it's not actually a good path to go
down.

> A fixed-length array is not a good future-proof solution.up

Agreed.

I'm not responding to the details of Gary's or Carlos's notions about an
interface for this, because I think that the whole direction is probably
not what we want to do.

I'll just point out one item of trivia: it's already the case that gdb
looks for known a special symbol name.  If it doesn't find DT_DEBUG, then
it looks for a symbol called "_r_debug".  This is today what makes it
handle statically-linked programs that do dynamic linking at runtime (a
possibility that exists only in glibc and not in other implementations;
you can use -ldl, or implicitly use NSS modules, under -static, though you
will get nasty warnings because it's so fraught with peril in practice).

The whole style of the scheme with DT_DEBUG, struct r_debug, etc. is a
very old protocol from the dawn of ELF in SVR4.  Since then we've
learned a lot more about what are and aren't good ideas.  The Solaris
addition of librtld_db was many years later, but now quite a few years
ago--and we've learned more since then, too.

It's my sense that none of these are good approaches in the context of
modern GDB.  The simplistic methods like DT_DEBUG and what you are
proposing here are not very good because they hamstring future
implementation changes with an ABI compatibility requirement to support
old debuggers by sticking with fixed data structures.  The versioning
ideas mitigate this only a very little bit.  (To wit, r_version has
never changed because it would be too much trouble.)  The idea of a
library like librtld_db or libthread_db is somewhat more attractive, but
it in practice is a non-option for cross-debugging and can be a real
pain for versioning issues too.  (You need a libthread_db.so that
exactly matches your libc version, so for a single debugger installation
to be able to debug multiple different vintages of inferior worlds can
be difficult.  When I rewrote libthread_db in 2003 to solve the biarch
problem, I took pains to make it so the libthread_db code could
theoretically be built on a different host for use in cross-debugging,
but nobody has ever bothered with the hassle of building it that way.)

Nowadays, we have an entirely different and IMHO much better option for
this sort of thing.  I've said before that I want to see GDB abandon
using libthread_db in favor of this approach too.  That is, the same
approach GDB now supports for application-specific pretty-printing:
Python code to run in GDB that comes with the application.  Just as
libstdc++ now comes with Python code to pretty-print STL data
structures, libc can come with Python code to interpret its internal
ld.so and libpthread data structures.  That code can know all manner of
internals about the implementation, because it goes with the debuggee
code rather than with the debugger code.

There is not much work required in libc to do these things.  Most of the
work is on the GDB side, to make it possible for Python hooks to satisfy
the internal purposes for which GDB today uses libthread_db or the
DT_DEBUG/r_debug/link_map data structures.  If Gary or someone else will
take up the GDB work and get it to the point that you can write some
simple Python code to mock up loaded-objects information and have GDB
use that information (for extra credit, do the same for the libthread_db
stuff), then we can whip up appropriate Python code for the actual
dynamic linker internals easily enough.


Thanks,
Roland