From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31740 invoked by alias); 29 Mar 2005 04:17:21 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31675 invoked from network); 29 Mar 2005 04:17:17 -0000 Received: from unknown (HELO heavymobile.ringle.org) (12.153.69.6) by sourceware.org with SMTP; 29 Mar 2005 04:17:17 -0000 Received: by heavymobile.ringle.org (Postfix, from userid 503) id 0B4236FE88; Mon, 28 Mar 2005 23:17:15 -0500 (EST) From: Jon Ringle To: gdb@sources.redhat.com Subject: Re: arm core analysis on x86 host Date: Tue, 29 Mar 2005 04:17:00 -0000 User-Agent: KMail/1.7.1 References: <200503281829.19775.jon.ringle@comdial.com> <20050328235715.GA3654@nevyn.them.org> In-Reply-To: <20050328235715.GA3654@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503282317.15105.jon.ringle@comdial.com> X-SW-Source: 2005-03/txt/msg00277.txt.bz2 On Monday 28 March 2005 18:57, Daniel Jacobowitz wrote: > On Mon, Mar 28, 2005 at 06:29:19PM -0500, Jon Ringle wrote: > > I find that the only place that core_stratum gets used to set to_stratum > > is in init_core_ops(), which gets called by _initialize_corelow(). > > However, I can't find any code that calls _initialize_corelow(). > > It's called from init.c, which is a generated file, if it is included in > the gdb build. See the .mh and .mt files. Ok. I added corelow.o to gdb/config/arm/linux.mt and now _initialize_corelow() is being called. > > On Monday 28 March 2005 18:57, Daniel Jacobowitz wrote: > > > Take a look at any target which registers core functions in a tdep > > > file, instead of a nat file. arm-linux still does it in the nat file. > > > That just needs to be fixed. > > > > I looked at mips-linux-tdep.c as an example and it uses: > > deprecated_add_core_fns (®set_core_fns); > > > > Is there a non-deprecated version I should be use instead? Is there a > > better example to follow? > Try anything using set_gdbarch_regset_from_core_section. I am now using as an example ppc-linux-tdep.c, however it still seems that a call to deprecated_add_core_fns() is needed. When I use a 'target core /path/to/core' command, core_open() gets called which calls sniff_core_bfd(). sniff_core_bfd() has a loop to iterate over core_file_fns, which as far as I can tell gets populated via deprecated_add_core_fns(). I don't see how else core_file_fns gets populated. Am I misunderstanding the use of 'deprecated' here? My understanding of the word is that use is no longer desired in favor of a (hopefully) better solution or archetecture. Jon