From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16778 invoked by alias); 1 Dec 2004 04:31:16 -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 16691 invoked from network); 1 Dec 2004 04:31:08 -0000 Received: from unknown (HELO priv-edtnes27.telusplanet.net) (199.185.220.223) by sourceware.org with SMTP; 1 Dec 2004 04:31:08 -0000 Received: from takamaka.act-europe.fr ([142.179.108.108]) by priv-edtnes27.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20041201043107.SWL16341.priv-edtnes27.telusplanet.net@takamaka.act-europe.fr> for ; Tue, 30 Nov 2004 21:31:07 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 8A2A347DA6; Tue, 30 Nov 2004 20:31:06 -0800 (PST) Date: Wed, 01 Dec 2004 04:31:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFA/alpha] Fix problem loading core files Message-ID: <20041201043106.GP1204@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2004-12/txt/msg00006.txt.bz2 I noticed that GDB is no longer able to load the registers from a core file: (gdb) core core OK -> Core was generated by `crash'. OK -> Program terminated with signal 6, Aborted. !?! -> Register not found in core file. That lead me to a couple of issues. First, in fetch_osf_core_registers() in alpha-nat.c; we have an array named core_reg_mapping[ALPHA_NUM_REGS] which value is statically defined (minus a #if ... #else ... #endif twist): static int const core_reg_mapping[ALPHA_NUM_REGS] = { #ifdef NCF_REGS #define EFL NCF_REGS CF_V0, CF_T0, CF_T1, CF_T2, CF_T3, CF_T4, CF_T5, CF_T6, [...]. The problem is that ALPHA_NUM_REGS has been incremented on 2003-01-31: * alpha-nat.c (REGISTER_PTRACE_ADDR): Merge into ... (register_addr): ... here. Support ALPHA_UNIQUE_REGNUM. (fetch_elf_core_registers): Support ALPHA_UNIQUE_REGNUM. * alpha-tdep.c (alpha_register_name): Add "unique". * alpha-tdep.h (ALPHA_NUM_REGS): Increment. (ALPHA_UNIQUE_REGNUM): New. * config/alpha/nm-linux.h (ALPHA_UNIQUE_PTRACE_ADDR): New. But the table was not updated in consequence. So I added an index of -1 for this extra register in the table. So the number of elements in the value matches the number of elements declared. But that was not the problem that caused the error above. What happens is that we removed a vitual register on 2003-06-01: * alpha-tdep.h (ALPHA_FP_REGNUM): Remove. * alpha-tdep.c (alpha_register_name): Remove vfp entry. (alpha_cannot_fetch_register): Remove ALPHA_FP_REGNUM. (alpha_cannot_store_register): Likewise. * alphabsd-nat.c (fetch_inferior_registers): Don't set FP_REGNUM. * alpha-nat.c (supply_gregset): Likewise. * alphanbsd-tdep.c (fetch_core_registers): Likewise. The register index was kept reserved to maintain compatibility with alpha remote debug agents. But the problem is that now alpha_cannot_fetch_register() considers this old register as fetchable, which is not true. As a consequence, fetch_osf_core_registers() finds an inconsistency because on the one hand it has a negative offset (-1), and on the other hand it has a register that presumably is fetchable. And hence we get the error. This patch modified alpha_cannot_fetch_register() and alpha_cannot_store_register() to exclude the register which have an empty name. These empty names are the sign of a register number that is no longer used, but has been reserved to maintain compatibility with remote debug agents. 2004-11-30 Joel Brobecker * alpha-tdep.c (alpha_register_name): Add comment. (alpha_cannot_fetch_register): Exclude register number which are no longer used from the list of registers that can be fetched. (alpha_cannot_store_register): Exclude register number which are no longer used from the list of registers that can be stored. Tested on alpha-tru64. Makes the following changes to the testsuite results: * gdb.base: +------------+------------+----------------------------------------------------+ | FAIL | PASS | corefile.exp: args: -core=corefile | | FAIL | PASS | corefile.exp: args: execfile -core=corefile | | FAIL | PASS | corefile.exp: core-file command | | FAIL | PASS | corefile.exp: print func2::coremaker_local | | FAIL | PASS | corefile.exp: backtrace in corefile.exp | +------------+------------+----------------------------------------------------+ OK to apply? Thanks, -- Joel