From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11179 invoked by alias); 15 Sep 2006 20:00:23 -0000 Received: (qmail 11165 invoked by uid 22791); 15 Sep 2006 20:00:22 -0000 X-Spam-Check-By: sourceware.org Received: from sinclair.provo.novell.com (HELO sinclair.provo.novell.com) (137.65.248.137) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 15 Sep 2006 20:00:17 +0000 Received: from INET-PRV-MTA by sinclair.provo.novell.com with Novell_GroupWise; Fri, 15 Sep 2006 14:00:16 -0600 Message-Id: <450AB1E5.742A.00E2.0@novell.com> X-Mailer: Novell GroupWise Internet Agent 7.0.1 Date: Fri, 15 Sep 2006 20:00:00 -0000 From: "Steve Eaton" To: Subject: RE: preserving gdb symbols Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-09/txt/msg00088.txt.bz2 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" 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