This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
[PATCH] MIPS: Go back with the default Linux # of registers to 90
- From: "Maciej W. Rozycki" <macro at imgtec dot com>
- To: Orgad Shaneh <orgads at gmail dot com>
- Cc: Pedro Alves <palves at redhat dot com>, Luis Machado <lgustavo at codesourcery dot com>, <gdb-patches at sourceware dot org>
- Date: Mon, 18 Apr 2016 14:17:18 +0100
- Subject: [PATCH] MIPS: Go back with the default Linux # of registers to 90
- Authentication-results: sourceware.org; auth=none
Set the number of registers for non-XML-described Linux targets to 90,
reverting a change made here with the addition of DSP register support:
commit 1faeff088bbbd037d7769d214378b4faf805fa2e
Author: Maciej W. Rozycki <macro@linux-mips.org>
Date: Thu Mar 1 22:19:48 2012 +0000
and fixing a regression introduced for legacy `gdbserver' targets
causing a "Remote 'g' packet reply is too long" error message where the
amount of register data received with a `g' packet (90) exceeds the
maximum number of registers expected (79).
Update the setting for XML-described targets, reflecting the actual
number of registers which have been assigned numbers, matching the:
gdb_assert (gdbarch_num_regs (gdbarch) <= MIPS_RESTART_REGNUM);
requirement in `mips_linux_init_abi'.
gdb/
* mips-tdep.c (mips_gdbarch_init): For GDB_OSABI_LINUX set
`num_regs' to 90 rather than 79. Where a target description is
present adjust the setting appropriately.
---
Orgad,
Can you please check if this change addresses your problem?
I'm not currently set up to fully regression-test this change with
`gdbserver', but I did some manual testing and things look right. The
change for `num_regs' in the XML-described case (which is now either 72 or
79, for non-DSP and DSP targets respectively, rather than always 79) is in
particular going to be always overridden in `mips_linux_init_abi' with
`MIPS_RESTART_REGNUM + 1' (80) anyway -- we don't have proper support for
XML-described bare-metal targets, so only the Linux target matters. So I
think this patch is safe and I'm going to install it once I've got a
confirmation that the legacy case has been addressed.
Maciej
gdb-mips-gdbarch-init-linux-num-regs.diff
Index: binutils/gdb/mips-tdep.c
===================================================================
--- binutils.orig/gdb/mips-tdep.c 2016-04-18 11:53:07.592133428 +0100
+++ binutils/gdb/mips-tdep.c 2016-04-18 12:30:58.698574753 +0100
@@ -8192,7 +8192,7 @@ mips_gdbarch_init (struct gdbarch_info i
mips_regnum.dspctl = -1;
dspacc = 72;
dspctl = 78;
- num_regs = 79;
+ num_regs = 90;
reg_names = mips_linux_reg_names;
}
else
@@ -8311,6 +8311,8 @@ mips_gdbarch_init (struct gdbarch_info i
return NULL;
}
+ num_regs = mips_regnum.fp_implementation_revision + 1;
+
if (dspacc >= 0)
{
feature = tdesc_find_feature (info.target_desc,
@@ -8344,6 +8346,8 @@ mips_gdbarch_init (struct gdbarch_info i
mips_regnum.dspacc = dspacc;
mips_regnum.dspctl = dspctl;
+
+ num_regs = mips_regnum.dspctl + 1;
}
}