This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: gdb and dynamic loader namespaces
On Mon, 2007-01-08 at 10:15 -0500, Daniel Jacobowitz wrote:
> On Mon, Jan 08, 2007 at 04:09:58PM +0100, Mathieu Lacage wrote:
> > So, I tried to figure out how I could fix this in gdb: a bit of
> > debugging shows that gdb is notified of dlmopen calls through the
> > r_debug structure since "set stop-on-solib-events 1" triggers correctly
> > an event upon dlmopen. The question then is why gdb does not add the new
> > binary to its map. Maybe someone more knowledgeable than me about the
> > layout of the gdb code source could point me to the piece of code which
> > updates and manipulates the gdb map of binaries used during symbol
> > lookup ? (I am using an x86 linux system)
>
> It's in solib-svr4.c. Look especially at current_sos and compare that
> to where glibc adds things in namespaces. I doubt they're on the same
> list, and in fact they may not even be listed in the public part of
> struct r_debug.
They are not, indeed in the public part of r_debug. My understanding is
that the rtld_global data structure (see sysdeps/generic/ldsodefs.h)
contains an array of struct link_namespaces, each of which contains a
struct r_debug. The first entry in this array is supposed to represent
the LD_ID_BASE which is the default namespace: it is not super clear to
me what is the relationship between the struct r_debug embedded in the
associated struct link_namespace and the global _r_debug variable used
to hold the process struct r_debug. The latter seems to be the default
value used to initialize the dynamic loader's DT_DEBUG entry which you
use for all your debugging needs in solib-svr4.c.
The question then is how can we get access to the link_map of each
namespace from the parent process ? We could perform a lookup for the
rtld_global data structure and then, use an offset from there to get the
required data. I suspect you won't be thrilled by that though. Do you
have any better idea ? Maybe I should ask this question on a glibc ML: I
would be surprised if no one had ever planned debugger support for this
feature.
Mathieu
--