This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
[PING] dlmopen and core dumps
- From: Gary Benson <gbenson at redhat dot com>
- To: libc-alpha at sourceware dot org
- Date: Wed, 12 Dec 2012 16:59:28 +0000
- Subject: [PING] dlmopen and core dumps
- References: <20121105132108.GA4305@redhat.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/