From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6073 invoked by alias); 1 Dec 2004 14:00:04 -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 5976 invoked from network); 1 Dec 2004 13:59:55 -0000 Received: from unknown (HELO krynn.se.axis.com) (193.13.178.10) by sourceware.org with SMTP; 1 Dec 2004 13:59:55 -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 iB1DxsAD006132; Wed, 1 Dec 2004 14:59:54 +0100 Message-ID: <41ADCE5B.5010001@axis.com> Date: Wed, 01 Dec 2004 14:00: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: gdb-patches@sources.redhat.com, Hans-Peter Nilsson Subject: [CRIS] Reading core file selects "wrong" mach Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00015.txt.bz2 When reading a CRISv32 Linux core file, the "wrong" mach is selected, causing cris_elf_grok_prstatus to not find the general-purpose registers (because unlike other ports it actually checks bfd_get_mach (abfd)). 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). Is there an implicit assumption that the mach is not to be trusted when reading a core file? (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.) -- Orjan Friberg Axis Communications