This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [SH] PATCH: Define the register groups
- From: Andrew STUBBS <andrew dot stubbs at st dot com>
- To: Daniel Jacobowitz <drow at false dot org>, gdb-patches at sources dot redhat dot com
- Date: Mon, 23 Jan 2006 15:48:44 +0000
- Subject: Re: [SH] PATCH: Define the register groups
- References: <436105B8.7020605@st.com> <436F6CF7.1070003@st.com> <20060120233520.GJ21181@nevyn.them.org>
Daniel Jacobowitz wrote:
- Are the fv registers for floating point vectors? Since you
put them in both info float and info vector. I'm guessing that
they are. Makes sense.
Yes.
- Can we reuse default_register_reggroup_p for most of this, and
just handle the register numbers that it's likely to get
wrong? e.g. we probably do need to handle FPUL here - but
calling the default will handle dr0 just fine.
Yes, I hadn't thought of that, but I suppose it can. I attach an
implementation of this patch. Actually, FPUL is handled fine, but FPSCR
is not, and, more to the point, none of the vector registers are.
- You've put a bunch of registers in system_reggroup (e.g. pc, pr)
that other folks don't; but no one besides the TUI uses that
anyway, so it doesn't really matter. I wouldn't have included
those two. I don't remember what the other ones you listed do,
so I've got no idea about them :-)
Well, there is, of course, a debate to be had over many of the
registers. I have included FPSCR, a system register, in the float
reggroup because (to the initiated) it helps you read the other float
registers. I'm not really sure what system_reggroup is supposed to be
for - I imagine sr (status register) that control various features (FPU,
exceptions etc.) of the CPU is a definite member of this group. Others
are less clear - how about spc and spr which are like pc and pr for
exceptions. Incidentally, insight also uses these groups.
The attached patch has pc and pr moved from system to general. I have
also moved GBR similarly. I had previously classified this as system
because it is not generally useful (the compiler does not normally
generate code that uses it), but on reflection it just isn't a system
register.
At the end of the day the important thing is that 'info registers',
'info float' and 'info vector' print the right thing.
OK?
Andrew Stubbs
P.S. Your email headers contain:
Mail-Followup-To: Andrew STUBBS <andrew.stubbs@st.com>,
gdb-patches@sources.redhat.com
which means I end up replying to myself! Is this deliberate? It is
slightly irritating.
2006-01-23 Andrew Stubbs <andrew.stubbs@st.com>
* sh-tdep.c: Include reggroups.h.
(sh_register_reggroup_p): New function.
(sh_gdbarch_init): Add call to set_gdbarch_register_reggroup_p.
* Makefile.in (sh-tdep.o): Add dependency on reggroups.h.
Index: src/gdb/sh-tdep.c
===================================================================
--- src.orig/gdb/sh-tdep.c 2006-01-16 12:44:50.000000000 +0000
+++ src/gdb/sh-tdep.c 2006-01-23 14:42:11.000000000 +0000
@@ -44,6 +44,7 @@
#include "regcache.h"
#include "doublest.h"
#include "osabi.h"
+#include "reggroups.h"
#include "sh-tdep.h"
@@ -1812,6 +1813,47 @@ sh_default_register_type (struct gdbarch
return builtin_type_int;
}
+/* Is a register in a reggroup?
+ The default code in reggroup.c doesn't identify system registers, some
+ float registers or any of the vector registers.
+ TODO: sh2a and dsp registers. */
+int
+sh_register_reggroup_p (struct gdbarch *gdbarch, int regnum,
+ struct reggroup *reggroup)
+{
+ if (REGISTER_NAME (regnum) == NULL
+ || *REGISTER_NAME (regnum) == '\0')
+ return 0;
+
+ if (reggroup == float_reggroup
+ && (regnum == FPUL_REGNUM
+ || regnum == FPSCR_REGNUM))
+ return 1;
+
+ if (regnum >= FV0_REGNUM && regnum <= FV_LAST_REGNUM)
+ {
+ if (reggroup == vector_reggroup || reggroup == float_reggroup)
+ return 1;
+ if (reggroup == general_reggroup)
+ return 0;
+ }
+
+ if (regnum == VBR_REGNUM
+ || regnum == SR_REGNUM
+ || regnum == FPSCR_REGNUM
+ || regnum == SSR_REGNUM
+ || regnum == SPC_REGNUM)
+ {
+ if (reggroup == system_reggroup)
+ return 1;
+ if (reggroup == general_reggroup)
+ return 0;
+ }
+
+ /* The default code can cope with any other registers. */
+ return default_register_reggroup_p (gdbarch, regnum, reggroup);
+}
+
/* On the sh4, the DRi pseudo registers are problematic if the target
is little endian. When the user writes one of those registers, for
instance with 'ser var $dr0=1', we want the double to be stored
@@ -2371,6 +2413,7 @@ sh_gdbarch_init (struct gdbarch_info inf
set_gdbarch_num_pseudo_regs (gdbarch, 0);
set_gdbarch_register_type (gdbarch, sh_default_register_type);
+ set_gdbarch_register_reggroup_p (gdbarch, sh_register_reggroup_p);
set_gdbarch_breakpoint_from_pc (gdbarch, sh_breakpoint_from_pc);
Index: src/gdb/Makefile.in
===================================================================
--- src.orig/gdb/Makefile.in 2006-01-23 12:33:23.000000000 +0000
+++ src/gdb/Makefile.in 2006-01-23 12:39:55.000000000 +0000
@@ -2538,7 +2538,7 @@ sh-tdep.o: sh-tdep.c $(defs_h) $(frame_h
$(value_h) $(dis_asm_h) $(inferior_h) $(gdb_string_h) \
$(gdb_assert_h) $(arch_utils_h) $(floatformat_h) $(regcache_h) \
$(doublest_h) $(osabi_h) $(sh_tdep_h) $(elf_bfd_h) $(solib_svr4_h) \
- $(elf_sh_h) $(gdb_sim_sh_h)
+ $(elf_sh_h) $(gdb_sim_sh_h) $(reggroups_h)
sol2-tdep.o: sol2-tdep.c $(defs_h) $(frame_h) $(symtab_h)
solib-aix5.o: solib-aix5.c $(defs_h) $(gdb_string_h) $(elf_external_h) \
$(symtab_h) $(bfd_h) $(symfile_h) $(objfiles_h) $(gdbcore_h) \