From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32175 invoked by alias); 30 Mar 2005 02:07:27 -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 31800 invoked from network); 30 Mar 2005 02:07:20 -0000 Received: from unknown (HELO heavymobile.ringle.org) (12.153.69.6) by sourceware.org with SMTP; 30 Mar 2005 02:07:20 -0000 Received: by heavymobile.ringle.org (Postfix, from userid 503) id C5EC86FCE6; Tue, 29 Mar 2005 21:07:18 -0500 (EST) From: Jon Ringle To: gdb@sources.redhat.com Subject: Re: arm core analysis on x86 host Date: Wed, 30 Mar 2005 02:07:00 -0000 User-Agent: KMail/1.7.1 References: <200503281829.19775.jon.ringle@comdial.com> <200503291139.15566.jon.ringle@comdial.com> <20050329165316.GA11679@nevyn.them.org> In-Reply-To: <20050329165316.GA11679@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200503292107.17776.jon.ringle@comdial.com> X-SW-Source: 2005-03/txt/msg00293.txt.bz2 On Tuesday 29 March 2005 11:53, Daniel Jacobowitz wrote: > On Tue, Mar 29, 2005 at 11:39:15AM -0500, Jon Ringle wrote: > > On Tuesday 29 March 2005 11:33, Daniel Jacobowitz wrote: > > > On Tue, Mar 29, 2005 at 11:13:53AM -0500, Jon Ringle wrote: > > > > On Monday 28 March 2005 23:58, Daniel Jacobowitz wrote: > > > > > 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? > > > > I put a call to set_gdbarch_regset_from_core_section at the end of > > arm_linux_init_abi(), just like ppc_linux_init_abi(). > > Trace through the gdbarch initialization to see what's going on, then. > The core file may not be recognized as a Linux object. This has > happened on other platforms; I don't know what was done about it, but > maybe Mark remembers. Daniel, Is the problem that the osabi for the file and target don't match? (gdb) file ippbx.gdb find_arch_by_info: info.bfd_arch_info arm find_arch_by_info: info.byte_order 1 (little) find_arch_by_info: info.osabi 5 (GNU/Linux) find_arch_by_info: info.abfd 0x849e558 find_arch_by_info: info.tdep_info 0x0 find_arch_by_info: Previous architecture 0x0848e430 (arm) selected Reading symbols from /home/ringlej/mp1000/trunk-fixes/Soundpipe/ippbx/ippbx.gdb...done. (gdb) target core ./core find_arch_by_info: info.bfd_arch_info arm find_arch_by_info: info.byte_order 1 (little) find_arch_by_info: info.osabi 21 (ARM APCS) find_arch_by_info: info.abfd 0x84a0450 find_arch_by_info: info.tdep_info 0x0 find_arch_by_info: New architecture 0x08571958 (arm) selected Jon