From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2238 invoked by alias); 22 Apr 2009 19:18:55 -0000 Received: (qmail 2228 invoked by uid 22791); 22 Apr 2009 19:18:54 -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; Wed, 22 Apr 2009 19:18:49 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 474D02BAB45 for ; Wed, 22 Apr 2009 15:18:45 -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 zc+GJrcI-kY4 for ; Wed, 22 Apr 2009 15:18:45 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 122EB2BAB29 for ; Wed, 22 Apr 2009 15:18:45 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 42D8CF5886; Wed, 22 Apr 2009 12:18:33 -0700 (PDT) Date: Wed, 22 Apr 2009 19:37:00 -0000 From: Joel Brobecker To: gdb@sourceware.org Subject: Questions on how to implement native core file support Message-ID: <20090422191833.GM23807@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) 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/msg00186.txt.bz2 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? 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? -- Joel