From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3849 invoked by alias); 7 May 2009 15:04:26 -0000 Received: (qmail 3710 invoked by uid 22791); 7 May 2009 15:04:24 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 07 May 2009 15:04:16 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 3A0952BAB58; Thu, 7 May 2009 11:04:14 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id fO+G-FFWIjD2; Thu, 7 May 2009 11:04:14 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id EE6022BAB2E; Thu, 7 May 2009 11:04:13 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 01947F5900; Thu, 7 May 2009 08:04:12 -0700 (PDT) Date: Thu, 07 May 2009 15:04:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sourceware.org Subject: Re: [RFA/doco] Adding support for core file debugging... Message-ID: <20090507150411.GC659@adacore.com> References: <20090506234011.GD20299@adacore.com> <83ljp9d2n7.fsf@gnu.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5QAgd0e35j3NYeGe" Content-Disposition: inline In-Reply-To: <83ljp9d2n7.fsf@gnu.org> User-Agent: Mutt/1.5.18 (2008-05-17) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-05/txt/msg00155.txt.bz2 --5QAgd0e35j3NYeGe Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 609 > > 2009-05-06 Joel Brobecker > > > > * gdbint.texinfo (Adding support for debugging core files): New node. > > (Native Debugging): Remove the ``Native core file Support'' section. > > > > Tested by rebuilding the documentation. > > OK to apply? > > Yes, but maybe add some @cindex entry there. Sure. Based on how the other cindex entries were designed (from the associated section name), I added: +@cindex core files I don't see anything else that might be useful to help finding this section... So here is a second version of the patch. Thanks, -- Joel --5QAgd0e35j3NYeGe Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="core-files-doc.diff" Content-length: 4747 commit f23e3b5af8c4ee6bfff43b2b404d2965c9693a16 Author: Joel Brobecker Date: Wed May 6 16:35:43 2009 -0700 * gdbint.texinfo (Adding support for debugging core files): New node. (Native Debugging): Remove the ``Native core file Support'' section. diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo index a07a572..c25a180 100644 --- a/gdb/doc/gdbint.texinfo +++ b/gdb/doc/gdbint.texinfo @@ -2831,6 +2831,7 @@ using the Bourne shell script @file{gdbarch.sh}. * Register Representation:: * Frame Interpretation:: * Inferior Call Setup:: +* Adding support for debugging core files:: * Defining Other Architecture Features:: * Adding a New Target:: @end menu @@ -4420,6 +4421,17 @@ Some Harvard architectures may not allow this. @end deftypefn +@node Adding support for debugging core files +@section Adding support for debugging core files +@cindex core files + +The prerequisite for adding core file support in @value{GDBN} is to have +core file support in BFD. + +Once BFD support is available, writing the apropriate +@code{regset_from_core_section} architecture function should be all +that is needed in order to add support for core files in @value{GDBN}. + @node Defining Other Architecture Features @section Defining Other Architecture Features @@ -5408,64 +5420,6 @@ This is the low level interface to inferior processes for systems using the Unix @code{ptrace} call in a vanilla way. @end table -@section Native core file Support -@cindex native core files - -@table @file -@findex fetch_core_registers -@item core-aout.c::fetch_core_registers() -Support for reading registers out of a core file. This routine calls -@code{register_addr()}, see below. Now that BFD is used to read core -files, virtually all machines should use @code{core-aout.c}, and should -just provide @code{fetch_core_registers} in @code{@var{xyz}-nat.c} (or -@code{REGISTER_U_ADDR} in @code{nm-@var{xyz}.h}). - -@item core-aout.c::register_addr() -If your @code{nm-@var{xyz}.h} file defines the macro -@code{REGISTER_U_ADDR(addr, blockend, regno)}, it should be defined to -set @code{addr} to the offset within the @samp{user} struct of @value{GDBN} -register number @code{regno}. @code{blockend} is the offset within the -``upage'' of @code{u.u_ar0}. If @code{REGISTER_U_ADDR} is defined, -@file{core-aout.c} will define the @code{register_addr()} function and -use the macro in it. If you do not define @code{REGISTER_U_ADDR}, but -you are using the standard @code{fetch_core_registers()}, you will need -to define your own version of @code{register_addr()}, put it into your -@code{@var{xyz}-nat.c} file, and be sure @code{@var{xyz}-nat.o} is in -the @code{NATDEPFILES} list. If you have your own -@code{fetch_core_registers()}, you may not need a separate -@code{register_addr()}. Many custom @code{fetch_core_registers()} -implementations simply locate the registers themselves.@refill -@end table - -When making @value{GDBN} run native on a new operating system, to make it -possible to debug core files, you will need to either write specific -code for parsing your OS's core files, or customize -@file{bfd/trad-core.c}. First, use whatever @code{#include} files your -machine uses to define the struct of registers that is accessible -(possibly in the u-area) in a core file (rather than -@file{machine/reg.h}), and an include file that defines whatever header -exists on a core file (e.g., the u-area or a @code{struct core}). Then -modify @code{trad_unix_core_file_p} to use these values to set up the -section information for the data segment, stack segment, any other -segments in the core file (perhaps shared library contents or control -information), ``registers'' segment, and if there are two discontiguous -sets of registers (e.g., integer and float), the ``reg2'' segment. This -section information basically delimits areas in the core file in a -standard way, which the section-reading routines in BFD know how to seek -around in. - -Then back in @value{GDBN}, you need a matching routine called -@code{fetch_core_registers}. If you can use the generic one, it's in -@file{core-aout.c}; if not, it's in your @file{@var{xyz}-nat.c} file. -It will be passed a char pointer to the entire ``registers'' segment, -its length, and a zero; or a char pointer to the entire ``regs2'' -segment, its length, and a 2. The routine should suck out the supplied -register values and install them into @value{GDBN}'s ``registers'' array. - -If your system uses @file{/proc} to control processes, and uses ELF -format core files, then you may be able to use the same routines for -reading the registers out of processes and out of core files. - @section ptrace @section /proc --5QAgd0e35j3NYeGe--