gdb and dynamic loader namespaces

gdb and dynamic loader namespaces

[Mathieu Lacage]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

hi,

While playing a bit with the dlmopen (this is the stock glibc coming
with a FC5 system) function, it occured to me that gdb 6.6 does not seem
to be able to deal with code loaded in a process through this function.
The attached test program shows that, indeed an extra binary is loaded
in my process address space but gdb seems unable to place a breakpoint
in any of the functions defined in this binary (something like "b
gtk_window_new"). 

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)

I apologize before hand if this email is off-topic,

regards,
Mathieu
-- 

[-- Attachment #2: test.c --]
[-- Type: text/x-csrc, Size: 1209 bytes --]

#define _GNU_SOURCE

#include <dlfcn.h>
#include <link.h>
#include <stdio.h>

static void print_map (struct link_map *map)
{
  struct link_map *tmp;
  for (tmp = map; tmp != 0; tmp = tmp->l_next)
    {
      printf ("  0x%lx: \"%s\"\n", tmp->l_addr, tmp->l_name?tmp->l_name:"null");
    }
}

int main (int argc, char *argv[])
{
  void * handle;
  struct link_map *map;
  dlerror ();
  handle = dlopen (NULL, RTLD_LAZY);
  if (handle == NULL) 
    {
      printf ("error getting handle for main binary: %s\n", dlerror ());
      goto error;
    }
  if (dlinfo (handle, RTLD_DI_LINKMAP, &map) == -1) 
    {
      printf ("error getting link map: %s\n", dlerror ());
      goto error;
    }

  printf ("map before dlmopen\n");
  print_map (map);

  void *module = dlmopen (LM_ID_NEWLM, "/usr/lib/libgtk-x11-2.0.so", RTLD_NOW);	
  if (module == 0) {
    printf ("error=\"%s\"", dlerror ());
    return;
  }


  printf ("default map after dlmopen\n");
  print_map (map);


  if (dlinfo (module, RTLD_DI_LINKMAP, &map) == -1) 
    {
      printf ("error getting 2nd link map: %s\n", dlerror ());
      goto error;
    }

  printf ("2nd map after dlmopen\n");
  print_map (map);


  return 0;
 error:
  return -1;
}

Re: gdb and dynamic loader namespaces

[Daniel Jacobowitz]

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.

I'm not sure what gdb would really do with them either.  It doesn't
support multiple namespaces of symbols.


-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb and dynamic loader namespaces

[mathieu lacage]

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.

thanks,

> 
> I'm not sure what gdb would really do with them either.  It doesn't
> support multiple namespaces of symbols.

The (probably naive) idea would be to merge them: they live in separate
address spaces so address lookups should be unique. name lookups, on the
other hand, could be non-unique but this is nothing new: gdb should
already be able to handle multiple answers for a single name lookup,
right ?

Mathieu

Re: gdb and dynamic loader namespaces

[Daniel Jacobowitz]

On Mon, Jan 08, 2007 at 05:44:48PM +0100, mathieu lacage wrote:
> > I'm not sure what gdb would really do with them either.  It doesn't
> > support multiple namespaces of symbols.
> 
> The (probably naive) idea would be to merge them: they live in separate
> address spaces so address lookups should be unique. name lookups, on the
> other hand, could be non-unique but this is nothing new: gdb should
> already be able to handle multiple answers for a single name lookup,
> right ?

Well, mostly it ignores the issue.  We could handle them the same as
dlopen which would probably be more useful than ignoring them entirely.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb and dynamic loader namespaces

[Mathieu Lacage]

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
-- 

Re: gdb and dynamic loader namespaces

[Daniel Jacobowitz]

On Tue, Jan 09, 2007 at 08:57:08AM +0100, Mathieu Lacage wrote:
> 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.

It may require updating the public members of struct r_debug (and its
version number).  I would recommend not digging around in rtld_global,
at least not without talking to the glibc developers first; it's prone
to changing layout between versions.  You could see what Solaris does,
if it's in their documentation.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gdb and dynamic loader namespaces

[mathieu lacage]

[answer to an old email]

On Tue, 2007-01-09 at 08:41 -0500, Daniel Jacobowitz wrote:
> On Tue, Jan 09, 2007 at 08:57:08AM +0100, Mathieu Lacage wrote:
> > 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.
> 
> It may require updating the public members of struct r_debug (and its
> version number).  I would recommend not digging around in rtld_global,
> at least not without talking to the glibc developers first; it's prone
> to changing layout between versions.  You could see what Solaris does,
> if it's in their documentation.

It is in their documentation. As far as I can tell, they use the rtld_db
API (see chapter 6 of the "Linker and Libraries Guide") to access the
underlying data structures. They even provide a version of rtld_db which
works on linux except that it has been hardcoded to deal with only the
main namespace on linux. Being able to fully implement the library would
require intimate access to the glibc data structures. So, I suspect that
the implementation challenge would be:
  - push a rtld_db library in glibc
  - add rtld_db support to gdb

regards,
Mathieu