This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Chicken-or-egg problem with shared libraries
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 #=-