RE: preserving gdb symbols

["Steve Eaton" <seaton@novell.com>]

We have the same problem.  You are correct that you can run ldd against
the exec file, and then you have to run that across each and every
shared file it lists as they can load others.  Also I am not sure if
that shows you ones where people use function tables and load them on
the fly.  You don't need all shared libraries, but if someone dumps core
how are you going to programmatically figure out what ones you need for
you entire core.


I wonder if the principal of what mmalloc did was worth while.  While
it was removed cause it isn't working, I would be willing to code it up
if it was generally accepted and agreed upon.

Steve

>>> "Michael Snyder" <Michael.Snyder@palmsource.com> 9/14/2006 12:01 PM
>>>

I am not sure if I understand what your goal is.
Is it that you want to package up the core file, 
together with all (or some) of the shared libraries
on which it depends, for later debugging on a different
machine?

Seems like you could get at least some of that info
by running ldd on the exec file.  

Are you sure you need to have *all* of the shared
libraries?  

-----Original Message-----
From: gdb-owner@sourceware.org on behalf of Lee
Sent: Thu 9/14/2006 10:49 AM
To: gdb@sources.redhat.com 
Subject: preserving gdb symbols
 
Sorry, one more painful shared library symbol
question.

When I have a customer's machine core, I can open the
core with something like 

gdb --readnow /usr/bin/myapp core.1234

gdb then reads the binaries to read in the needed
symtabs 

I now have every symbol in memory that I need for what
I am doing.  

Currently i have to use a script to read all of the
loaded statements, parse it, and pipe that out and tar
up all of the needed libraries so that I can get
matching binaries for shared libraries and have a
useful core to read. This is usually in the order of
60 to 100 shared libraries).  We ofcourse are doing
this on HPUX, linux (redhat and suse), and solaris. 
So getting every vendor to change their core format
while probably the best option, is not very likely.

So my question is first of all is there any way I can
just save all of the symbol information I have in
memory, so that I can reload it when reading the core
on a different machine.   

If not, then we are still stuck with always having to
have the exact shared library to read the symbols
from.
The gnu_debug_link is even worthless as u have to read
that out of the actual shared library, its not in the
core. 

I modified solib_read_symbols.  I changed it so that
if you added a switch on gdb's command line then each
time a call was made to solib_read_symbols I then kept
the file.  In my case I used the command interface to
exec tar.  A person could tack them on the end of the
core file, or create your own package in whatever
format is generally acceptable.  Would a solution of
anything like this be acceptable to get back into the
gdb source ?

Lee



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