From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9943 invoked by alias); 29 Mar 2005 16:33:38 -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 8365 invoked from network); 29 Mar 2005 16:32:24 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 29 Mar 2005 16:32:24 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DGJeh-0002Kb-0c; Tue, 29 Mar 2005 11:33:27 -0500 Date: Tue, 29 Mar 2005 16:33:00 -0000 From: Daniel Jacobowitz To: Jon Ringle Cc: gdb@sources.redhat.com Subject: Re: arm core analysis on x86 host Message-ID: <20050329163326.GA8753@nevyn.them.org> Mail-Followup-To: Jon Ringle , gdb@sources.redhat.com References: <200503281829.19775.jon.ringle@comdial.com> <200503282317.15105.jon.ringle@comdial.com> <20050329045853.GA11420@nevyn.them.org> <200503291113.53817.jon.ringle@comdial.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200503291113.53817.jon.ringle@comdial.com> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-03/txt/msg00280.txt.bz2 On Tue, Mar 29, 2005 at 11:13:53AM -0500, Jon Ringle wrote: > On Monday 28 March 2005 23:58, Daniel Jacobowitz wrote: > > On Mon, Mar 28, 2005 at 11:17:14PM -0500, Jon Ringle wrote: > > > 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. > > > > Look harder :-) sniff_core_bfd is disabled if you provide the new > > mechanism. It should be all you need. > > I assume that you are refering to the test that is done at the beginning of > sniff_core_bfd(): > /* Don't sniff if we have support for register sets in CORE_GDBARCH. */ > if (core_gdbarch && gdbarch_regset_from_core_section_p (core_gdbarch)) > return NULL; > > Howerver, the value of core_gdbarch is not the same as the gdbarch that was > used for the set_gdbarch_regset_from_core_section() causing the test to fail > and fall through to the core_file_fns loop. The two being different is not a problem; however, the question is why they are so different that they do not both pass through wherever you are calling set_gdbarch_regset_from_core_section. At least two gdbarches will be constructed before the core file is opened, but you only show one call to set_gdbarch_regset_from_core_section. Where did you put it? -- Daniel Jacobowitz CodeSourcery, LLC