From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5216 invoked by alias); 17 Aug 2006 03:10:50 -0000 Received: (qmail 5198 invoked by uid 22791); 17 Aug 2006 03:10:49 -0000 X-Spam-Check-By: sourceware.org Received: from web55609.mail.re4.yahoo.com (HELO web55609.mail.re4.yahoo.com) (206.190.58.233) by sourceware.org (qpsmtpd/0.31) with SMTP; Thu, 17 Aug 2006 03:10:43 +0000 Received: (qmail 1120 invoked by uid 60001); 17 Aug 2006 03:10:41 -0000 Message-ID: <20060817031041.1118.qmail@web55609.mail.re4.yahoo.com> Received: from [66.236.68.185] by web55609.mail.re4.yahoo.com via HTTP; Wed, 16 Aug 2006 20:10:36 PDT Date: Thu, 17 Aug 2006 03:10:00 -0000 From: Lee Subject: debugging release shared libraries To: gdb@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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-08/txt/msg00132.txt.bz2 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