Re: debugging a dynamically loaded library

[Kevin Buettner <kevinb at cygnus dot com>]

On Sep 18,  5:10pm, Mike Krogh wrote:

> Can you tell me if any more progress has been made with this problem?
> Do you have any ETA on when a resolution might be available?

A patch has been checked into the GDB development sources which "fixes"
the problem noted by H.J.  The reason that I put "fixes" in quotes is
that there is also a bug in the linker (or possibly some other part
of the toolchain) which causes a weak defined symbol to be changed to
a weak undefined symbol under some circumstances.  The stabs entries
for this (now undefined) symbol are still retained however.  Thus,
under these conditions, it may still be possible for GDB to produce
unexpected behavior, but I don't think this is unreasonable since GDB's
sources of debugging information are inconsistent with each other. 
I.e, one source says that the symbol is undefined while the other, in
essence, is saying that the symbol is defined by providing line number
information for the function.

In any event, the patch in question does allow me to successfully debug
your example program on a Red Hat Linux 7.1 system.  I don't think that
there were any issues with debugging your example program on a Red Hat
Linux 6.2 system.  (These were the two platforms that you were testing
on, right?)

> Anything I might be able to do?

Yes!  Fetch a copy of the development sources and test GDB against
your test case as well the application that caused you to report
this problem in the first place.

BTW, the ChangeLog entry for the patch in question is as follows:

2001-09-06  Kevin Buettner  <kevinb@redhat.com>
	
	* dbxread.c (process_one_symbol): Don't use error result from
	find_stab_function_addr().
	* partial-stab.h (case 'F'): Likewise.

	* partial-stab.h (case 'f'): Make SOFUN_ADDRESS_MAYBE_MISSING
	code match that used for case 'F'.  This fixes the divergence
	that was introduced by my 1999-09-14 changes to partial-stab.h.

Thanks,

Kevin