From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA/alpha] Fix problem loading core files
Date: Wed, 01 Dec 2004 04:31:00 -0000 [thread overview]
Message-ID: <20041201043106.GP1204@adacore.com> (raw)
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 <brobecker@gnat.com>
* 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
next reply other threads:[~2004-12-01 4:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-01 4:31 Joel Brobecker [this message]
2004-12-01 4:57 ` Joel Brobecker
2004-12-01 5:13 ` Daniel Jacobowitz
2004-12-01 17:18 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041201043106.GP1204@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox