RE: preserving gdb symbols

["Michael Snyder" <Michael.Snyder@palmsource.com>]

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