From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15891 invoked by alias); 2 Dec 2004 17:18:44 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15872 invoked from network); 2 Dec 2004 17:18:38 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 2 Dec 2004 17:18:38 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iB2HIUkM027910; Thu, 2 Dec 2004 18:18:30 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iB2HIUol004813; Thu, 2 Dec 2004 18:18:30 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iB2HIK1Q004810; Thu, 2 Dec 2004 18:18:20 +0100 (CET) Date: Thu, 02 Dec 2004 17:18:00 -0000 Message-Id: <200412021718.iB2HIK1Q004810@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: orjan.friberg@axis.com CC: gdb-patches@sources.redhat.com, hans-peter.nilsson@axis.com In-reply-to: <41ADCE5B.5010001@axis.com> (message from Orjan Friberg on Wed, 01 Dec 2004 14:59:55 +0100) Subject: Re: [CRIS] Reading core file selects "wrong" mach References: <41ADCE5B.5010001@axis.com> X-SW-Source: 2004-12/txt/msg00045.txt.bz2 Date: Wed, 01 Dec 2004 14:59:55 +0100 From: Orjan Friberg The reason seems to be the call to bfd_default_set_arch_mach (abfd, ebd->arch, 0) in elf_core_file_p in elfcore.h which will select the default mach for that arch. Directly after this we start reading the core file which results in a call to cris_elf_grok_prstatus (which fails because the default mach doesn't match the current mach). Without that call to bfd_default_set_arch_mach(), the architecture/machine wouldn't be set at all for the core file BFD. Is there an implicit assumption that the mach is not to be trusted when reading a core file? What do you mean by "not to be trusted"? It's simply always set to the default machine for ELF core files. For most architectures this is what makes the most sense anyway. Setting it to anything different from the default would involve some architecture-dependent code. I guess the correct way to do this would be adding elf_set_mach_from_flags() to `struct elf_backend_data', and use that in elf_core_file_p() to set the machine after the architecture has been set. In principle, GDB can deal with core file BFD's that set the BFD machine as well as the BFD architecture. This is done in netbsd-core.c to distinguish between 32-bit and 64-bit processors (sparc vs. sparc64, i386 vs. amd64). There are some issue's though with compatibility between various BFD machines. Depending on how compatibility is defined for a certain BFD architecture, you might need to register a GDB OS/ABI for every BFD machine for your BFD architecture. (For reference: e_flags, checked in set_mach_from_flags, is hardcoded to 0 in the Linux kernel, but setting it correctly (to EF_CRIS_VARIANT_V32 in this case) wouldn't change a thing because of the above.) (That would have to change then. The file gcore.c will probably also need some changes.) Mark