debugging release shared libraries

debugging release shared libraries

[Lee]

I have one problem that I have not found a good
solution for with gdb.
I realize that gdb is only half of the solution for a
core, I wasn't sure which group to start with.    I
use several platforms, but for now lets assume shared
libs are elf-i386, using linux.

On other platforms when a core file is generated it
contains all of the basic symbols that a person needs
to see why things blew up, examine the stack, threads
whatever.  If symbols are needed you can match them to
a sym file or pdb file and they can even be auto
magically matched up with the binary in question in
the dump. checksum and such.

On linux I am working with applications that use
numerous shared libraries.  Symbols are more than
frustrating to me.   A short example

you run 
./foo
foo then loads 
libc.so.
libdl.so
libnsl.so      
ld-linux.so.
libfred.so

libfred.so then loads
libc.so
libren.so
libstimpy.so
and so on.

This can go on for like 50 shared libraries.

Now the problem part
We dump core

someone emails me the core to debug.
the libraries of course are not debug nor is the
application

if you have the luxury of debugging the core on the
remote machine wherever that might be then all is well
as gdb will load whatever symbols it needs from the
prog and the so files.

if you are lucky enough to know the exact versions of
all 50+ shared libs the machine is running then you
can create a chroot jail and run it in gdb on my
machine

You can of course always have symbols if you care to
compile every shared library and the prog with -g and
then distribute the huge libraries.  

I have also looked into compiling with -g, then
stripping the files creating debug files and using
add-gnu-debuglink.   Even this has issues as I still
have to have all of the exact same versions as is on
the machine in question so that those shared libraries
can tell me the correct version of debug file to load.

It just seems that there is just no way to get around
having all of the binaries to debug a core, or compile
everything with -g and always running the larger
libraries.

Any ideas would greatly be appreciated.





__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: debugging release shared libraries

[Daniel Jacobowitz]

On Wed, Aug 16, 2006 at 08:10:36PM -0700, Lee wrote:
> It just seems that there is just no way to get around
> having all of the binaries to debug a core, or compile
> everything with -g and always running the larger
> libraries.

Or as you mentioned use .gnu_debuglink to run the smaller libraries,
but yes, if the libraries aren't in your core dump then you need to
know exactly which ones they were.

Someone recently proposed to include shared libraries in core dumps on
linux-kernel, but the patch didn't get much attention.  I think it was
David Miller.

-- 
Daniel Jacobowitz
CodeSourcery