dlmopen and core dumps

[Gary Benson <gbenson at redhat dot com>]

Hi all,

I've been looking into ways of allowing debuggers to see libraries
loaded into namespaces other than the initial namespace with dlmopen.
The SystemTap probes added to the runtime linker recently make such
libraries visible during live debugging, but there is currently no way
to access them from core dumps.  I'd like to discuss some ideas to
make this possible with the view of submitting a patch.

Currently, only the r_debug structure of the initial namespace is
visible to the debugger, which reads its location from the DT_DEBUG
element of the executable's dynamic section.  The simplest way to make
the other namespaces available (as I see it) would be to also expose
the r_debug structures for the other namespaces somehow.

There are two questions really, what format should the data be in, and
how should the debugger discover it.

The obvious way to expose the structures would be in a linked list.
It *could* be done with a fixed-length array--namespaces are not
currently allocated dynamically--but this would cause problems for any
future hacker trying to remove this restriction, so I'm not seriously
proposing that.

If it is to be a linked list, there are two possibilities for what it
should contain.  It could contain only active namespaces, which would
require some maintainence as namespaces were created and destroyed, or
it could be allowed to contain empty namespaces, in which case the
list could be set up by the linker at startup and then forgotten
about.  I prefer the former, but I'm happy with the latter too.

If it is to be a linked list, a data structure for the list would be
needed somewhere.  Would link.h be a good place for it?

Concerning how the debugger would discover the new structure, I can
think of two ways.  One would be to add another element to the dynamic
section, DT_DEBUG_EXTENDED or something similar.  I don't know the
process for doing this (is there some group that controls the ELF
format?)  The other way would be to have some specifically named
symbol that debuggers could locate, perhaps restricting their search
to the object containing the symbol referenced in DT_DEBUG.  I'm
happy with either of these solutions, but I don't know enough to say
if one or the other has problems so I'd appreciate feedback.

The final consideration is how to version the new interface.  I'm
presuming that other interfaces glibc implements have some kind of
versioning information, but I'm not familiar enough with everything to
pick some specific example.  My instict says to go for a pair of
integers, a major and a minor version, such that nonbreaking changes
increment the minor version and breaking changes increment the major
and reset the minor.  If so, is it best to put two ints in the exposed
structure, or maybe just one with the major version encoded in the
upper bits?  If there is a standard way interfaces are versioned (or
an example of a good interface) then I'm happy to follow that.

Thanks,
Gary

-- 
http://gbenson.net/