From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14961 invoked by alias); 22 Apr 2009 19:37:33 -0000 Received: (qmail 14951 invoked by uid 22791); 22 Apr 2009 19:37:32 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Apr 2009 19:37:26 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3) with ESMTP id n3MJaac6003842; Wed, 22 Apr 2009 21:36:36 +0200 (CEST) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.3/8.14.3/Submit) id n3MJaaeX027562; Wed, 22 Apr 2009 21:36:36 +0200 (CEST) Date: Fri, 24 Apr 2009 14:31:00 -0000 Message-Id: <200904221936.n3MJaaeX027562@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: brobecker@adacore.com CC: gdb@sourceware.org In-reply-to: <20090422191833.GM23807@adacore.com> (message from Joel Brobecker on Wed, 22 Apr 2009 12:18:33 -0700) Subject: Re: Questions on how to implement native core file support References: <20090422191833.GM23807@adacore.com> 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: 2009-04/txt/msg00187.txt.bz2 > Date: Wed, 22 Apr 2009 12:18:33 -0700 > From: Joel Brobecker > > Hello, > > While looking at expunging REGISTER_U_ADDR from our documentation > (no longer used), I found out that the documentation about how to > provide core file support is out of date (core-aout has been deleted > a year ago). > > Having never written support for core file reading, I have tried > to figure out how to add it. As far as I can tell, I can see > two forms of core file support: > > 1. Native core file support > 2. gdbarch core file support > > In the second case, it appears that all you have to do is define > the gdbarch_regset_from_core_section method for your architecture, > and I would guess that this is the prefered method. However, may > not be always doable, in particular if you depend on certain > system headers... Any other possible reason? You never have to depend on system headers. The right thing to do is add support to BFD for the core file format in question. That code should compile on any system, and relevant constants and data structures should go in a header file in the toplevel include directory. After that, writing the appropriate gdbarch_regset_from_core_section() function is all that's needed on the GDB side. We certainly should avoid adding more "native core file support" code. > In the first case, it looks like core_low is relying on > a struct core_fns which is provides pointers to various > target-dependent routines. The thing is, the routine I see > in order to register a particular instance is marked as > deprecated: > > extern void deprecated_add_core_fns (struct core_fns *cf); > > Does it mean that, as of today, we only consider the second > gdbarch-based approach? If that's the case, then should we simply > update the documentation to either remove the "Native core file Support" > section, or replace it with a link to gdbarch_regset_from_core_section? I think so.