Re: Chicken-or-egg problem with shared libraries

[PAUL GILLIAM <pgilliam@us.ibm.com>]

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