Chicken-or-egg problem with shared libraries

Chicken-or-egg problem with shared libraries

[PAUL GILLIAM]

In solib-svr4.c (enable_break), GDB tries to set a breakpoint in the
dynamic loader (at "_dl_debug_state") so that shared objects can be
tracked as they are loaded and unloaded.

The problem (on gnu/linux PowerPC64 at least) is that the dynamic loader
is it's self a shared object and its minimal symbols are not loaded when
"enable_break" is called.  

I have two ideas for fixing this: 1) pre-load the dynamic loaders
minimal symbols so that when "enable_break()" is called,
"_dl_debug_state" will be found and all is well and 2) allow
"enable_break()" to set a pending breakpoint.

The second idea has the problem of which name to use: "enable_break()"
currently tries five or six.

I like the first idea, but something is nagging the back of my mind
about it, but I don't know what.  I think we're talking about less the
20 minimal symbols and the name of the of the dynamic linker is in the
elf section '.interp'.  So that sounds straight forward.

Any advice?

-=# Paul #=-

Re: Chicken-or-egg problem with shared libraries

[Daniel Jacobowitz]

On Tue, May 23, 2006 at 02:04:26PM -0700, PAUL GILLIAM wrote:
> In solib-svr4.c (enable_break), GDB tries to set a breakpoint in the
> dynamic loader (at "_dl_debug_state") so that shared objects can be
> tracked as they are loaded and unloaded.
> 
> The problem (on gnu/linux PowerPC64 at least) is that the dynamic loader
> is it's self a shared object and its minimal symbols are not loaded when
> "enable_break" is called.  
> 
> I have two ideas for fixing this: 1) pre-load the dynamic loaders
> minimal symbols so that when "enable_break()" is called,
> "_dl_debug_state" will be found and all is well and 2) allow
> "enable_break()" to set a pending breakpoint.

I don't think you really understand the problem you're trying to fix -
what is it, by the way?  Is it related to Alan's comment earlier
about the function descriptor lookup?

Here's how it works today:

      bfd_get_section_contents (exec_bfd, interp_sect,
                                buf, 0, interp_sect_size);

      tmp_fd  = solib_open (buf, &tmp_pathname);
      if (tmp_fd >= 0)
        tmp_bfd = bfd_fopen (tmp_pathname, gnutarget, FOPEN_RB, tmp_fd);


          sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_CODE);
          if (sym_addr != 0)
            break;

-- 
Daniel Jacobowitz
CodeSourcery

Re: Chicken-or-egg problem with shared libraries

[PAUL GILLIAM]

On Tue, 2006-05-23 at 18:11 -0400, Daniel Jacobowitz wrote:
> I don't think you really understand the problem you're trying to fix -
> what is it, by the way?  Is it related to Alan's comment earlier
> about the function descriptor lookup?
> 
(sigh) You're right...  I didn't look close enough.

The problem I am trying to fix is that this gets executed:

bkpt_at_symbol:
  warning (_("Unable to find dynamic linker breakpoint function.\n"
           "GDB will be unable to debug shared library initializers\n"
           "and track explicitly loaded dynamic code."));

I believe this is executed because although it finds
"_dl_debug_state" (now that Alan made his change to BFD), on a ppc64
system, that symbol is not in the a code section and so it is rejected:

>   sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_CODE);
                                                       ^^^^^^^^^

The next symbol in the list being looked for is "._dl_debug_state",
which is no longer to be found sense Alan removed the 'dot' symbols a
while back.

I guess I'll have to call "bfd_get_synthetic_symtab()" and look in the
synthetic symtab it creates.  Of course I'll have to first read in the
dynamic symbol table which "bfd_get_synthetic_symtab()" needs.

That should work.  The only down side is that that work is then thrown
away and then repeated when the symbols for the shared object that is
the dynamic loader are read in later.  But for 20 symbols or so, I guess
that's not too bad.

Thanks for setting me straight,

-=# Paul #=-
 

Re: Chicken-or-egg problem with shared libraries

[Daniel Jacobowitz]

On Tue, May 23, 2006 at 02:56:17PM -0700, PAUL GILLIAM wrote:
> bkpt_at_symbol:
>   warning (_("Unable to find dynamic linker breakpoint function.\n"
>            "GDB will be unable to debug shared library initializers\n"
>            "and track explicitly loaded dynamic code."));
> 
> I believe this is executed because although it finds
> "_dl_debug_state" (now that Alan made his change to BFD), on a ppc64
> system, that symbol is not in the a code section and so it is rejected:
> 
> >   sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_CODE);
>                                                        ^^^^^^^^^

I understood from Alan that GDB ought to actually deal with the
function descriptor here and go from that to the code address; or is
that wrong?

[I'm clueless for function descriptor platforms.]

-- 
Daniel Jacobowitz
CodeSourcery

Re: Chicken-or-egg problem with shared libraries

[PAUL GILLIAM]

On Tue, 2006-05-23 at 19:02 -0400, Daniel Jacobowitz wrote:
> On Tue, May 23, 2006 at 02:56:17PM -0700, PAUL GILLIAM wrote:
> > bkpt_at_symbol:
> >   warning (_("Unable to find dynamic linker breakpoint function.\n"
> >            "GDB will be unable to debug shared library initializers\n"
> >            "and track explicitly loaded dynamic code."));
> > 
> > I believe this is executed because although it finds
> > "_dl_debug_state" (now that Alan made his change to BFD), on a ppc64
> > system, that symbol is not in the a code section and so it is rejected:
> > 
> > >   sym_addr = bfd_lookup_symbol (tmp_bfd, *bkpt_namep, SEC_CODE);
> >                                                        ^^^^^^^^^
> 
> I understood from Alan that GDB ought to actually deal with the
> function descriptor here and go from that to the code address; or is
> that wrong?

What Alan thinks is that GDB should do so *everywhere*, not just here.

What we do instead is to synthesize the 'dot' symbols, essentially
dealing with this problem once, when the symbols are loaded, rather than
each time a function's entry point address is needed.  Here is a recent
statement of Alan's:

> Really, gdb should be taught how to do without the synthetic sym crutch.

The fancy way would be to do the translation as needed, but cache the
results.

I don't want to solve this today, just so that this breakpoint can be
set: I am content to continue using the synthetic sym crutch for a while
longer.  This particular need for the crutch was just overlooked when
the use of 'dot' symbols was originally abandoned.

-=# Paul #=-