This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [SH] PATCH: Define the register groups


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) \

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]