[PING] dlmopen and core dumps

[Gary Benson <gbenson at redhat dot com>]

Gary Benson wrote:
> 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/