From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6129 invoked by alias); 10 Dec 2008 22:15:08 -0000 Received: (qmail 6071 invoked by uid 22791); 10 Dec 2008 22:15:07 -0000 X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Dec 2008 22:14:20 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mBAMEEqZ001202; Wed, 10 Dec 2008 17:14:14 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mBAMED8O031800; Wed, 10 Dec 2008 17:14:13 -0500 Received: from host0.dyn.jankratochvil.net (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id mBAMEBWH019676; Wed, 10 Dec 2008 17:14:12 -0500 Received: from host0.dyn.jankratochvil.net (localhost [127.0.0.1]) by host0.dyn.jankratochvil.net (8.14.3/8.14.3) with ESMTP id mBAME9rv022717; Wed, 10 Dec 2008 23:14:10 +0100 Received: (from jkratoch@localhost) by host0.dyn.jankratochvil.net (8.14.3/8.14.2/Submit) id mBAME9sp022714; Wed, 10 Dec 2008 23:14:09 +0100 Date: Wed, 10 Dec 2008 22:15:00 -0000 From: Jan Kratochvil To: Paul Smith Cc: gdb@sourceware.org Subject: Re: Classifying core files? Message-ID: <20081210221408.GA13433@host0.dyn.jankratochvil.net> References: <1228842548.2017.64.camel@psmith-ubeta.netezza.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1228842548.2017.64.camel@psmith-ubeta.netezza.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-12/txt/msg00033.txt.bz2 On Tue, 09 Dec 2008 18:09:08 +0100, Paul Smith wrote: > What I have at my disposal is a bunch of local and cross-debuggers and > gcc/binutils suites, a bunch of potential executables that cores could > come from, and a bunch of shared objects that might or might not have > been loaded. And, a core file. With old and/or non-Linux cores/executables there is no way to safely associate them. It may be some heuristics such as checking some _r_debug linklist validity but it is nothing much reliable, if possible at all. The primary problem is that in the core files the readonly (commonly .text and .rodata) pages are just omitted and readwrite pages cannot be compared as sure they could be / usually are already modified in the core dumping time. I do not understand much if you can generate new core files or if you are just interested in the existing core files you have. In the former case there are some possibilities: For recent Linux kernels you may get the full dumps (incl. the readonly pages) using /proc//coredump_filter (see its doc). But still it will be complicated to find the appropriate file containing the debuginfo for it. More efficient and recommended would be build-ids: With recent (2007 Oct+) Linux kernel the core files now contain also the first page of the mapped ELF files. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=82df39738ba9e02c057fa99b7461a56117d36119 If you build your distro using `ld --build-id' (default for Fedora since Fedora 8) each binary has its unique id and so this unique id is present also in the core files. Described at: http://fedoraproject.org/wiki/Releases/FeatureBuildId FSF GDB currently contains only the faster verification the separate .debug files. There is a patch going to be hopefully integrated one day which supports automatically finding the right binary just being given a bare core file (`gdb -c ./core.1234'). For gdb-6.8: http://cvs.fedora.redhat.com/viewvc/rpms/gdb/devel/gdb-6.6-buildid-locate.patch?view=co For GDB HEAD: http://people.redhat.com/jkratoch/gdb-6.8.50.20081209-buildid-locate.patch It still has currently merged two unrelated functionalities: (a) The expected locating of appropriate binaries from a bare core file. (b) Reporting missing debuginfo rpms from missing .debug files. > What I'm trying to do is generate a script that can determine the right > set of GDB executable, GDB command line options (to "set sysroot", > etc.), etc., starting with only the core file itself as information, > then invoke GDB properly. Yes, it works as described although it understandably requires the appropriate symlinks (files) for the build-id hash mapping: lrwxrwxrwx 1 root root 23 2008-10-30 11:57 /usr/lib/debug/.build-id/29/93b8ca46989e7434eef8daf61f31e9f8d6a0ba -> ../../../../../bin/bash -rwxr-xr-x 1 root root 834520 2008-10-28 22:37 /bin/bash lrwxrwxrwx 1 root root 20 2008-10-30 11:57 /usr/lib/debug/.build-id/29/93b8ca46989e7434eef8daf61f31e9f8d6a0ba.debug -> ../../bin/bash.debug -rwxr-xr-x 1 root root 1903112 2008-10-28 22:37 /usr/lib/debug/bin/bash.debug (possibly placed in a separate sysroot) Patched GDB also loads the shared libraries according to their build-id hashes. Regards, Jan