From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18784 invoked by alias); 13 Dec 2004 14:41:52 -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 18193 invoked from network); 13 Dec 2004 14:41:10 -0000 Received: from unknown (HELO krynn.se.axis.com) (193.13.178.10) by sourceware.org with SMTP; 13 Dec 2004 14:41:10 -0000 Received: from [10.84.130.1] (ironmaiden.se.axis.com [10.84.130.1]) by krynn.se.axis.com (8.12.9/8.12.9/Debian-5local0.1) with ESMTP id iBDEf5mp022744; Mon, 13 Dec 2004 15:41:05 +0100 Message-ID: <41BDAA01.6080101@axis.com> Date: Mon, 13 Dec 2004 15:12:00 -0000 From: Orjan Friberg Organization: Axis Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913 MIME-Version: 1.0 To: Mark Kettenis CC: gdb-patches@sources.redhat.com, hans-peter.nilsson@axis.com Subject: Re: [CRIS] Reading core file selects "wrong" mach References: <41ADCE5B.5010001@axis.com> <200412021718.iB2HIK1Q004810@elgar.sibelius.xs4all.nl> In-Reply-To: <200412021718.iB2HIK1Q004810@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00355.txt.bz2 Mark Kettenis wrote: > 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. Yes, I didn't mean to say that the call to bfd_default_set_arch_mach was wrong or superfluous, I was just describing the effect it had. > 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 What I meant was that I couldn't find any other port that looked at the mach in their grok_prstatus/grok_prinfo, which led me to think there might be a reason they didn't. > 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. Yes, that makes sense. Thanks. I guess the answer to this is 'no', but would it be possible (and correct) to use whatever machine was set when loading the corresponding program into GDB? -- Orjan Friberg Axis Communications