RFA: make sim interface use gdbarch methods for collect/supply

RFA: make sim interface use gdbarch methods for collect/supply

[Jim Blandy]

[-- Attachment #1: Type: text/plain, Size: 339 bytes --]


At the moment, remote-sim.c's gdbsim_fetch_register and
gdbsim_store_register functions assume that the simulator's register
set (as visible via sim_fetch_register and sim_store_register)
corresponds exactly to GDB's raw register set.  This patch is meant to
remove that assumption.

Tested on i686-pc-linux-gnu x powerpc-eabispe (sim).


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: make sim use gdbarch methods to collect/supply registers --]
[-- Type: text/x-patch, Size: 17501 bytes --]

2004-06-30  Jim Blandy  <jimb@redhat.com>

	Don't assume that the sim's register set and GDB's raw register
	set have the same layout.
	* gdbarch.sh (sim_supply_register, sim_collect_register): New
	methods.  Have gdbarch.c #include regcache.h.
	* gdbarch.c, gdbarch.h: Regenerate.
	* remote-sim.c (gdbsim_fetch_register): Pass the register value
	collected from the sim to GDB via the new gdbarch methods.
	* Makefile.in (gdbarch.o): Update dependencies.

diff -rc gdb/gdbarch.c gdb/gdbarch.c
*** gdb/gdbarch.c	2004-06-22 12:30:54.000000000 -0500
--- gdb/gdbarch.c	2004-06-28 19:01:47.000000000 -0500
***************
*** 48,53 ****
--- 48,54 ----
  #include "gdb_string.h"
  #include "gdb-events.h"
  #include "reggroups.h"
+ #include "regcache.h"
  #include "osabi.h"
  #include "gdb_obstack.h"
  
***************
*** 166,171 ****
--- 167,174 ----
    gdbarch_print_float_info_ftype *print_float_info;
    gdbarch_print_vector_info_ftype *print_vector_info;
    gdbarch_register_sim_regno_ftype *register_sim_regno;
+   gdbarch_sim_supply_register_ftype *sim_supply_register;
+   gdbarch_sim_collect_register_ftype *sim_collect_register;
    gdbarch_register_bytes_ok_ftype *register_bytes_ok;
    gdbarch_cannot_fetch_register_ftype *cannot_fetch_register;
    gdbarch_cannot_store_register_ftype *cannot_store_register;
***************
*** 312,317 ****
--- 315,322 ----
    0,  /* print_float_info */
    0,  /* print_vector_info */
    0,  /* register_sim_regno */
+   0,  /* sim_supply_register */
+   0,  /* sim_collect_register */
    0,  /* register_bytes_ok */
    0,  /* cannot_fetch_register */
    0,  /* cannot_store_register */
***************
*** 452,457 ****
--- 457,464 ----
    current_gdbarch->call_dummy_location = AT_ENTRY_POINT;
    current_gdbarch->print_registers_info = default_print_registers_info;
    current_gdbarch->register_sim_regno = legacy_register_sim_regno;
+   current_gdbarch->sim_supply_register = regcache_raw_supply;
+   current_gdbarch->sim_collect_register = regcache_raw_collect;
    current_gdbarch->cannot_fetch_register = cannot_register_not;
    current_gdbarch->cannot_store_register = cannot_register_not;
    current_gdbarch->convert_register_p = generic_convert_register_p;
***************
*** 590,595 ****
--- 597,604 ----
    /* Skip verify of print_float_info, has predicate */
    /* Skip verify of print_vector_info, has predicate */
    /* Skip verify of register_sim_regno, invalid_p == 0 */
+   /* Skip verify of sim_supply_register, invalid_p == 0 */
+   /* Skip verify of sim_collect_register, invalid_p == 0 */
    /* Skip verify of register_bytes_ok, has predicate */
    /* Skip verify of cannot_fetch_register, invalid_p == 0 */
    /* Skip verify of cannot_store_register, invalid_p == 0 */
***************
*** 1907,1912 ****
--- 1916,1939 ----
    fprintf_unfiltered (file,
                        "gdbarch_dump: short_bit = %s\n",
                        paddr_d (current_gdbarch->short_bit));
+ #ifdef SIM_COLLECT_REGISTER
+   fprintf_unfiltered (file,
+                       "gdbarch_dump: %s # %s\n",
+                       "SIM_COLLECT_REGISTER(regcache, gdb_regno, buf)",
+                       XSTRING (SIM_COLLECT_REGISTER (regcache, gdb_regno, buf)));
+ #endif
+   fprintf_unfiltered (file,
+                       "gdbarch_dump: sim_collect_register = <0x%lx>\n",
+                       (long) current_gdbarch->sim_collect_register);
+ #ifdef SIM_SUPPLY_REGISTER
+   fprintf_unfiltered (file,
+                       "gdbarch_dump: %s # %s\n",
+                       "SIM_SUPPLY_REGISTER(regcache, gdb_regno, buf)",
+                       XSTRING (SIM_SUPPLY_REGISTER (regcache, gdb_regno, buf)));
+ #endif
+   fprintf_unfiltered (file,
+                       "gdbarch_dump: sim_supply_register = <0x%lx>\n",
+                       (long) current_gdbarch->sim_supply_register);
  #ifdef SKIP_PROLOGUE
    fprintf_unfiltered (file,
                        "gdbarch_dump: %s # %s\n",
***************
*** 3080,3085 ****
--- 3107,3146 ----
    gdbarch->register_sim_regno = register_sim_regno;
  }
  
+ void
+ gdbarch_sim_supply_register (struct gdbarch *gdbarch, struct regcache *regcache, int gdb_regno, const void *buf)
+ {
+   gdb_assert (gdbarch != NULL);
+   gdb_assert (gdbarch->sim_supply_register != NULL);
+   if (gdbarch_debug >= 2)
+     fprintf_unfiltered (gdb_stdlog, "gdbarch_sim_supply_register called\n");
+   gdbarch->sim_supply_register (regcache, gdb_regno, buf);
+ }
+ 
+ void
+ set_gdbarch_sim_supply_register (struct gdbarch *gdbarch,
+                                  gdbarch_sim_supply_register_ftype sim_supply_register)
+ {
+   gdbarch->sim_supply_register = sim_supply_register;
+ }
+ 
+ void
+ gdbarch_sim_collect_register (struct gdbarch *gdbarch, const struct regcache *regcache, int gdb_regno, void *buf)
+ {
+   gdb_assert (gdbarch != NULL);
+   gdb_assert (gdbarch->sim_collect_register != NULL);
+   if (gdbarch_debug >= 2)
+     fprintf_unfiltered (gdb_stdlog, "gdbarch_sim_collect_register called\n");
+   gdbarch->sim_collect_register (regcache, gdb_regno, buf);
+ }
+ 
+ void
+ set_gdbarch_sim_collect_register (struct gdbarch *gdbarch,
+                                   gdbarch_sim_collect_register_ftype sim_collect_register)
+ {
+   gdbarch->sim_collect_register = sim_collect_register;
+ }
+ 
  int
  gdbarch_register_bytes_ok_p (struct gdbarch *gdbarch)
  {
diff -rc gdb/gdbarch.h gdb/gdbarch.h
*** gdb/gdbarch.h	2004-06-22 12:30:54.000000000 -0500
--- gdb/gdbarch.h	2004-06-28 19:01:47.000000000 -0500
***************
*** 820,826 ****
  extern void gdbarch_print_vector_info (struct gdbarch *gdbarch, struct ui_file *file, struct frame_info *frame, const char *args);
  extern void set_gdbarch_print_vector_info (struct gdbarch *gdbarch, gdbarch_print_vector_info_ftype *print_vector_info);
  
! /* MAP a GDB RAW register number onto a simulator register number.  See
     also include/...-sim.h. */
  
  typedef int (gdbarch_register_sim_regno_ftype) (int reg_nr);
--- 820,830 ----
  extern void gdbarch_print_vector_info (struct gdbarch *gdbarch, struct ui_file *file, struct frame_info *frame, const char *args);
  extern void set_gdbarch_print_vector_info (struct gdbarch *gdbarch, gdbarch_print_vector_info_ftype *print_vector_info);
  
! /* The register set as implemented by the simulator may not line up
!    exactly with GDB's view of the raw register set.  The following
!    macros allow an architecture to make the appropriate adjustments to
!    register contents as they pass between GDB and the simulator.
!    Map a GDB RAW register number onto a simulator register number.  See
     also include/...-sim.h. */
  
  typedef int (gdbarch_register_sim_regno_ftype) (int reg_nr);
***************
*** 833,838 ****
--- 837,868 ----
  #define REGISTER_SIM_REGNO(reg_nr) (gdbarch_register_sim_regno (current_gdbarch, reg_nr))
  #endif
  
+ /* Supply the value of GDB_REGNO, in BUF, to REGCACHE.  GDB_REGNO is a
+    GDB register number, not a simulator register number. */
+ 
+ typedef void (gdbarch_sim_supply_register_ftype) (struct regcache *regcache, int gdb_regno, const void *buf);
+ extern void gdbarch_sim_supply_register (struct gdbarch *gdbarch, struct regcache *regcache, int gdb_regno, const void *buf);
+ extern void set_gdbarch_sim_supply_register (struct gdbarch *gdbarch, gdbarch_sim_supply_register_ftype *sim_supply_register);
+ #if (GDB_MULTI_ARCH > GDB_MULTI_ARCH_PARTIAL) && defined (SIM_SUPPLY_REGISTER)
+ #error "Non multi-arch definition of SIM_SUPPLY_REGISTER"
+ #endif
+ #if !defined (SIM_SUPPLY_REGISTER)
+ #define SIM_SUPPLY_REGISTER(regcache, gdb_regno, buf) (gdbarch_sim_supply_register (current_gdbarch, regcache, gdb_regno, buf))
+ #endif
+ 
+ /* Collect the value of GDB_REGNO from REGCACHE and place it in BUF.
+    GDB_REGNO is a GDB register number, not a simulator register number. */
+ 
+ typedef void (gdbarch_sim_collect_register_ftype) (const struct regcache *regcache, int gdb_regno, void *buf);
+ extern void gdbarch_sim_collect_register (struct gdbarch *gdbarch, const struct regcache *regcache, int gdb_regno, void *buf);
+ extern void set_gdbarch_sim_collect_register (struct gdbarch *gdbarch, gdbarch_sim_collect_register_ftype *sim_collect_register);
+ #if (GDB_MULTI_ARCH > GDB_MULTI_ARCH_PARTIAL) && defined (SIM_COLLECT_REGISTER)
+ #error "Non multi-arch definition of SIM_COLLECT_REGISTER"
+ #endif
+ #if !defined (SIM_COLLECT_REGISTER)
+ #define SIM_COLLECT_REGISTER(regcache, gdb_regno, buf) (gdbarch_sim_collect_register (current_gdbarch, regcache, gdb_regno, buf))
+ #endif
+ 
  #if defined (REGISTER_BYTES_OK)
  /* Legacy for systems yet to multi-arch REGISTER_BYTES_OK */
  #if !defined (REGISTER_BYTES_OK_P)
diff -rc gdb/gdbarch.sh gdb/gdbarch.sh
*** gdb/gdbarch.sh	2004-06-22 12:45:18.000000000 -0500
--- gdb/gdbarch.sh	2004-06-28 19:01:47.000000000 -0500
***************
*** 516,524 ****
  m::void:print_registers_info:struct ui_file *file, struct frame_info *frame, int regnum, int all:file, frame, regnum, all:::default_print_registers_info::0
  M::void:print_float_info:struct ui_file *file, struct frame_info *frame, const char *args:file, frame, args
  M::void:print_vector_info:struct ui_file *file, struct frame_info *frame, const char *args:file, frame, args
! # MAP a GDB RAW register number onto a simulator register number.  See
  # also include/...-sim.h.
  f:=:int:register_sim_regno:int reg_nr:reg_nr:::legacy_register_sim_regno::0
  F:=:int:register_bytes_ok:long nr_bytes:nr_bytes
  f:=:int:cannot_fetch_register:int regnum:regnum:::cannot_register_not::0
  f:=:int:cannot_store_register:int regnum:regnum:::cannot_register_not::0
--- 516,539 ----
  m::void:print_registers_info:struct ui_file *file, struct frame_info *frame, int regnum, int all:file, frame, regnum, all:::default_print_registers_info::0
  M::void:print_float_info:struct ui_file *file, struct frame_info *frame, const char *args:file, frame, args
  M::void:print_vector_info:struct ui_file *file, struct frame_info *frame, const char *args:file, frame, args
! 
! # The register set as implemented by the simulator may not line up
! # exactly with GDB's view of the raw register set.  The following
! # macros allow an architecture to make the appropriate adjustments to
! # register contents as they pass between GDB and the simulator.
! 
! # Map a GDB RAW register number onto a simulator register number.  See
  # also include/...-sim.h.
  f:=:int:register_sim_regno:int reg_nr:reg_nr:::legacy_register_sim_regno::0
+ 
+ # Supply the value of GDB_REGNO, in BUF, to REGCACHE.  GDB_REGNO is a
+ # GDB register number, not a simulator register number.
+ f:=:void:sim_supply_register:struct regcache *regcache, int gdb_regno, const void *buf:regcache, gdb_regno, buf:::regcache_raw_supply::0
+ 
+ # Collect the value of GDB_REGNO from REGCACHE and place it in BUF.
+ # GDB_REGNO is a GDB register number, not a simulator register number.
+ f:=:void:sim_collect_register:const struct regcache *regcache, int gdb_regno, void *buf:regcache, gdb_regno, buf:::regcache_raw_collect::0
+ 
  F:=:int:register_bytes_ok:long nr_bytes:nr_bytes
  f:=:int:cannot_fetch_register:int regnum:regnum:::cannot_register_not::0
  f:=:int:cannot_store_register:int regnum:regnum:::cannot_register_not::0
***************
*** 1228,1233 ****
--- 1243,1249 ----
  #include "gdb_string.h"
  #include "gdb-events.h"
  #include "reggroups.h"
+ #include "regcache.h"
  #include "osabi.h"
  #include "gdb_obstack.h"
  
diff -rc gdb/Makefile.in gdb/Makefile.in
*** gdb/Makefile.in	2004-06-28 18:39:59.000000000 -0500
--- gdb/Makefile.in	2004-06-28 19:01:47.000000000 -0500
***************
*** 1833,1839 ****
  	$(gdb_assert_h)
  gdbarch.o: gdbarch.c $(defs_h) $(arch_utils_h) $(gdbcmd_h) $(inferior_h) \
  	$(symcat_h) $(floatformat_h) $(gdb_assert_h) $(gdb_string_h) \
! 	$(gdb_events_h) $(reggroups_h) $(osabi_h) $(gdb_obstack_h)
  gdb.o: gdb.c $(defs_h) $(main_h) $(gdb_string_h) $(interps_h)
  gdb-events.o: gdb-events.c $(defs_h) $(gdb_events_h) $(gdbcmd_h)
  gdbtypes.o: gdbtypes.c $(defs_h) $(gdb_string_h) $(bfd_h) $(symtab_h) \
--- 1833,1840 ----
  	$(gdb_assert_h)
  gdbarch.o: gdbarch.c $(defs_h) $(arch_utils_h) $(gdbcmd_h) $(inferior_h) \
  	$(symcat_h) $(floatformat_h) $(gdb_assert_h) $(gdb_string_h) \
! 	$(gdb_events_h) $(reggroups_h) $(regcache_h) $(osabi_h) \
! 	$(gdb_obstack_h) 
  gdb.o: gdb.c $(defs_h) $(main_h) $(gdb_string_h) $(interps_h)
  gdb-events.o: gdb-events.c $(defs_h) $(gdb_events_h) $(gdbcmd_h)
  gdbtypes.o: gdbtypes.c $(defs_h) $(gdb_string_h) $(bfd_h) $(symtab_h) \
diff -rc gdb/remote-sim.c gdb/remote-sim.c
*** gdb/remote-sim.c	2004-06-28 18:54:34.000000000 -0500
--- gdb/remote-sim.c	2004-06-28 18:59:58.000000000 -0500
***************
*** 312,331 ****
      default:
        {
  	static int warn_user = 1;
  	char buf[MAX_REGISTER_SIZE];
  	int nr_bytes;
! 	gdb_assert (regno >= 0 && regno < NUM_REGS);
  	memset (buf, 0, MAX_REGISTER_SIZE);
! 	nr_bytes = sim_fetch_register (gdbsim_desc,
! 				       REGISTER_SIM_REGNO (regno),
! 				       buf, DEPRECATED_REGISTER_RAW_SIZE (regno));
! 	if (nr_bytes > 0 && nr_bytes != DEPRECATED_REGISTER_RAW_SIZE (regno) && warn_user)
  	  {
! 	    fprintf_unfiltered (gdb_stderr,
! 				"Size of register %s (%d/%d) incorrect (%d instead of %d))",
! 				REGISTER_NAME (regno),
! 				regno, REGISTER_SIM_REGNO (regno),
! 				nr_bytes, DEPRECATED_REGISTER_RAW_SIZE (regno));
  	    warn_user = 0;
  	  }
  	/* FIXME: cagney/2002-05-27: Should check `nr_bytes == 0'
--- 312,338 ----
      default:
        {
  	static int warn_user = 1;
+         int sim_regno = REGISTER_SIM_REGNO (regno);
  	char buf[MAX_REGISTER_SIZE];
  	int nr_bytes;
! 	gdb_assert (sim_regno >= 0 && sim_regno < NUM_REGS + NUM_PSEUDO_REGS);
  	memset (buf, 0, MAX_REGISTER_SIZE);
! 	nr_bytes
!           = sim_fetch_register (gdbsim_desc, sim_regno, buf,
!                                 DEPRECATED_REGISTER_RAW_SIZE (sim_regno));
! 	if (nr_bytes > 0
!             && nr_bytes != DEPRECATED_REGISTER_RAW_SIZE (sim_regno)
!             && warn_user)
  	  {
!             fprintf_unfiltered (gdb_stderr,
!                                 "GDB expected %d bytes for %s (%d)",
!                                 DEPRECATED_REGISTER_RAW_SIZE (sim_regno),
!                                 REGISTER_NAME (sim_regno), sim_regno);
!             if (sim_regno != regno)
!               fprintf_unfiltered (gdb_stderr, ", fetched for %s (%d)",
!                                   REGISTER_NAME (regno), regno);
!             fprintf_unfiltered (gdb_stderr, ", but sim provided %d",
!                                 nr_bytes);
  	    warn_user = 0;
  	  }
  	/* FIXME: cagney/2002-05-27: Should check `nr_bytes == 0'
***************
*** 333,344 ****
  	   which registers are fetchable.  */
  	/* Else if (nr_bytes < 0): an old simulator, that doesn't
  	   think to return the register size.  Just assume all is ok.  */
! 	supply_register (regno, buf);
  	if (sr_get_debug ())
  	  {
! 	    printf_filtered ("gdbsim_fetch_register: %d", regno);
  	    /* FIXME: We could print something more intelligible.  */
! 	    dump_mem (buf, DEPRECATED_REGISTER_RAW_SIZE (regno));
  	  }
  	break;
        }
--- 340,351 ----
  	   which registers are fetchable.  */
  	/* Else if (nr_bytes < 0): an old simulator, that doesn't
  	   think to return the register size.  Just assume all is ok.  */
! 	SIM_SUPPLY_REGISTER (current_regcache, regno, buf);
  	if (sr_get_debug ())
  	  {
! 	    printf_filtered ("gdbsim_fetch_register: %d", sim_regno);
  	    /* FIXME: We could print something more intelligible.  */
! 	    dump_mem (buf, DEPRECATED_REGISTER_RAW_SIZE (sim_regno));
  	  }
  	break;
        }
***************
*** 357,369 ****
      }
    else if (REGISTER_SIM_REGNO (regno) >= 0)
      {
        char tmp[MAX_REGISTER_SIZE];
        int nr_bytes;
!       deprecated_read_register_gen (regno, tmp);
!       nr_bytes = sim_store_register (gdbsim_desc,
! 				     REGISTER_SIM_REGNO (regno),
! 				     tmp, DEPRECATED_REGISTER_RAW_SIZE (regno));
!       if (nr_bytes > 0 && nr_bytes != DEPRECATED_REGISTER_RAW_SIZE (regno))
  	internal_error (__FILE__, __LINE__,
  			"Register size different to expected");
        /* FIXME: cagney/2002-05-27: Should check `nr_bytes == 0'
--- 364,376 ----
      }
    else if (REGISTER_SIM_REGNO (regno) >= 0)
      {
+       int sim_regno = REGISTER_SIM_REGNO (regno);
        char tmp[MAX_REGISTER_SIZE];
        int nr_bytes;
!       SIM_COLLECT_REGISTER (current_regcache, regno, tmp);
!       nr_bytes = sim_store_register (gdbsim_desc, sim_regno, tmp,
!                                      DEPRECATED_REGISTER_RAW_SIZE (sim_regno));
!       if (nr_bytes > 0 && nr_bytes != DEPRECATED_REGISTER_RAW_SIZE (sim_regno))
  	internal_error (__FILE__, __LINE__,
  			"Register size different to expected");
        /* FIXME: cagney/2002-05-27: Should check `nr_bytes == 0'
***************
*** 371,379 ****
  	 which registers are fetchable.  */
        if (sr_get_debug ())
  	{
! 	  printf_filtered ("gdbsim_store_register: %d", regno);
  	  /* FIXME: We could print something more intelligible.  */
! 	  dump_mem (tmp, DEPRECATED_REGISTER_RAW_SIZE (regno));
  	}
      }
  }
--- 378,386 ----
  	 which registers are fetchable.  */
        if (sr_get_debug ())
  	{
! 	  printf_filtered ("gdbsim_store_register: %d", sim_regno);
  	  /* FIXME: We could print something more intelligible.  */
! 	  dump_mem (tmp, DEPRECATED_REGISTER_RAW_SIZE (sim_regno));
  	}
      }
  }

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Daniel Jacobowitz]

On Wed, Jun 30, 2004 at 10:47:23AM -0500, Jim Blandy wrote:
> 
> At the moment, remote-sim.c's gdbsim_fetch_register and
> gdbsim_store_register functions assume that the simulator's register
> set (as visible via sim_fetch_register and sim_store_register)
> corresponds exactly to GDB's raw register set.  This patch is meant to
> remove that assumption.
> 
> Tested on i686-pc-linux-gnu x powerpc-eabispe (sim).

We've got a whole lot of new mechanism for describing register sets. 
Can't you use that instead of adding new supply/collect routines?

-- 
Daniel Jacobowitz

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:

> On Wed, Jun 30, 2004 at 10:47:23AM -0500, Jim Blandy wrote:
> > 
> > At the moment, remote-sim.c's gdbsim_fetch_register and
> > gdbsim_store_register functions assume that the simulator's register
> > set (as visible via sim_fetch_register and sim_store_register)
> > corresponds exactly to GDB's raw register set.  This patch is meant to
> > remove that assumption.
> > 
> > Tested on i686-pc-linux-gnu x powerpc-eabispe (sim).
> 
> We've got a whole lot of new mechanism for describing register sets. 
> Can't you use that instead of adding new supply/collect routines?

I'd love to use some existing mechanism, but I couldn't see how to
apply what I know of to this problem.  Can you give me a pointer?

If you mean the regset stuff: the sim doesn't present its registers in
terms of a single structure that one could pass to a
supply_regset_ftype or collect_regset_ftype value; you make one call
to a sim function to transfer each register.

I think what you're getting at is that SIM_COLLECT_REGISTER and
SIM_SUPPLY_REGISTER will in general have to re-implement some of the
raw/pseudo mapping.  I agree that that's unfortunate, but it's
inherent in the design: we can only collect and supply raw register
values, and our raw regcache layout is not necessarily the same as the
sim's register layout.

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Daniel Jacobowitz]

On Wed, Jun 30, 2004 at 12:00:16PM -0500, Jim Blandy wrote:
> Daniel Jacobowitz <drow@false.org> writes:
> 
> > On Wed, Jun 30, 2004 at 10:47:23AM -0500, Jim Blandy wrote:
> > > 
> > > At the moment, remote-sim.c's gdbsim_fetch_register and
> > > gdbsim_store_register functions assume that the simulator's register
> > > set (as visible via sim_fetch_register and sim_store_register)
> > > corresponds exactly to GDB's raw register set.  This patch is meant to
> > > remove that assumption.
> > > 
> > > Tested on i686-pc-linux-gnu x powerpc-eabispe (sim).
> > 
> > We've got a whole lot of new mechanism for describing register sets. 
> > Can't you use that instead of adding new supply/collect routines?
> 
> I'd love to use some existing mechanism, but I couldn't see how to
> apply what I know of to this problem.  Can you give me a pointer?
> 
> If you mean the regset stuff: the sim doesn't present its registers in
> terms of a single structure that one could pass to a
> supply_regset_ftype or collect_regset_ftype value; you make one call
> to a sim function to transfer each register.

The interface may need some surgery to do it, but the sim's registers
are conceptually a regset, aren't they?  We could collect each register
from the sim into a buffer and write a "struct regset" describing that.
This could happen in an arch-independent way in remote-sim, and then
the regset be provided by the target architecture.

> I think what you're getting at is that SIM_COLLECT_REGISTER and
> SIM_SUPPLY_REGISTER will in general have to re-implement some of the
> raw/pseudo mapping.  I agree that that's unfortunate, but it's
> inherent in the design: we can only collect and supply raw register
> values, and our raw regcache layout is not necessarily the same as the
> sim's register layout.

No, what I'm getting at is that I'd rather the number of interfaces for
accessing registers went down than up!  I want to standardize on using
the regset interface, because it's the most flexible.

-- 
Daniel Jacobowitz

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> > If you mean the regset stuff: the sim doesn't present its registers in
> > terms of a single structure that one could pass to a
> > supply_regset_ftype or collect_regset_ftype value; you make one call
> > to a sim function to transfer each register.
> 
> The interface may need some surgery to do it, but the sim's registers
> are conceptually a regset, aren't they?  We could collect each register
> >From the sim into a buffer and write a "struct regset" describing that.
> This could happen in an arch-independent way in remote-sim, and then
> the regset be provided by the target architecture.

Grumble.

So you're setting forth as an ideal that remote-sim.c would stop using
supply_register and collect_register altogether, and just use a
regset's supply and collect functions, right?

The regset interface isn't very well-suited for single-register
accesses.  Only the regset's collect and supply functions know which
bytes of the buffer are going to be used to supply a particular raw
register's value.  So when gdbsim_fetch_register is passed a specific
raw register number, it has no way of knowing which bytes of the
buffer to populate from the sim before it invokes the regset's supply
function.  For it to know that, it needs to know the correspondence
between the raw register cache and the cooked form provided by the
target --- but the whole point of introducing regsets in the first
place was to isolate that knowledge in regset supply and collect
functions.  So the sim would need to always read a full sim regset,
even when only one register was requested.

For the sim, that might all be in the noise, and not matter.  But if
you want to push the same sort of change through remote.c, then you
can't use that workaround.  For now, GDB's internal raw regcache
layout must correspond exactly to that of the 'g' packet, but I assume
that's not supposed to hold forever.  So when the remote protocol
registers don't exactly correspond to raw regcache registers, how will
GDB know where to place their contents in the buffer before calling
the supply function?

At the moment, regsets are used only to transfer entire register sets,
so we haven't run into it.

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Daniel Jacobowitz]

On Thu, Jul 01, 2004 at 12:22:25PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@false.org> writes:
> > > If you mean the regset stuff: the sim doesn't present its registers in
> > > terms of a single structure that one could pass to a
> > > supply_regset_ftype or collect_regset_ftype value; you make one call
> > > to a sim function to transfer each register.
> > 
> > The interface may need some surgery to do it, but the sim's registers
> > are conceptually a regset, aren't they?  We could collect each register
> > >From the sim into a buffer and write a "struct regset" describing that.
> > This could happen in an arch-independent way in remote-sim, and then
> > the regset be provided by the target architecture.
> 
> Grumble.
> 
> So you're setting forth as an ideal that remote-sim.c would stop using
> supply_register and collect_register altogether, and just use a
> regset's supply and collect functions, right?
> 
> The regset interface isn't very well-suited for single-register
> accesses.  Only the regset's collect and supply functions know which
> bytes of the buffer are going to be used to supply a particular raw
> register's value.  So when gdbsim_fetch_register is passed a specific
> raw register number, it has no way of knowing which bytes of the
> buffer to populate from the sim before it invokes the regset's supply
> function.  For it to know that, it needs to know the correspondence
> between the raw register cache and the cooked form provided by the
> target --- but the whole point of introducing regsets in the first
> place was to isolate that knowledge in regset supply and collect
> functions.  So the sim would need to always read a full sim regset,
> even when only one register was requested.

OK, that's a legitimate reason not to use regsets for this.  A reason
was all I wanted :) I still think it might be advantageous to always
fetch all registers for the sim case, though, and use regsets anyway.
We already do this for many native targets (PTRACE_GETREGS) because
that's lowest latency.

> For the sim, that might all be in the noise, and not matter.  But if
> you want to push the same sort of change through remote.c, then you
> can't use that workaround.  For now, GDB's internal raw regcache
> layout must correspond exactly to that of the 'g' packet, but I assume
> that's not supposed to hold forever.  So when the remote protocol
> registers don't exactly correspond to raw regcache registers, how will
> GDB know where to place their contents in the buffer before calling
> the supply function?
> 
> At the moment, regsets are used only to transfer entire register sets,
> so we haven't run into it.

GDB won't have to know where to place their contents in the buffer!
That's the point of using a regset.  You convert the 'g' packet output
to a binary blob in the obvious way, and then that's your regset.  The
target architecture supplies a regset that expects the format provided
by the 'g' packet.  Is there some problem with that plan?

-- 
Daniel Jacobowitz

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> GDB won't have to know where to place their contents in the buffer!
> That's the point of using a regset.  You convert the 'g' packet output
> to a binary blob in the obvious way, and then that's your regset.  The
> target architecture supplies a regset that expects the format provided
> by the 'g' packet.  Is there some problem with that plan?

No, regsets are perfect for 'g'.  I was thinking of the single-
register case (all under the assumption that we'd like to restrict
uses of supply_register and collect_register to regset functions).
What do you do with, say, the individual registers from your fancy 'T'
reply?

As far as I can tell, regsets don't serve this case well, which makes
them (in their current state) less than suitable as a universal
register transfer interface.

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Daniel Jacobowitz]

On Thu, Jul 01, 2004 at 01:44:53PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@false.org> writes:
> > GDB won't have to know where to place their contents in the buffer!
> > That's the point of using a regset.  You convert the 'g' packet output
> > to a binary blob in the obvious way, and then that's your regset.  The
> > target architecture supplies a regset that expects the format provided
> > by the 'g' packet.  Is there some problem with that plan?
> 
> No, regsets are perfect for 'g'.  I was thinking of the single-
> register case (all under the assumption that we'd like to restrict
> uses of supply_register and collect_register to regset functions).
> What do you do with, say, the individual registers from your fancy 'T'
> reply?

I have no idea.  Good question.

> 
> As far as I can tell, regsets don't serve this case well, which makes
> them (in their current state) less than suitable as a universal
> register transfer interface.
> 
> 


-- 
Daniel Jacobowitz

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Andrew Cagney]

> On Thu, Jul 01, 2004 at 01:44:53PM -0500, Jim Blandy wrote:
> 
>>> 
>>> Daniel Jacobowitz <drow@false.org> writes:
>>
>>>> > GDB won't have to know where to place their contents in the buffer!
>>>> > That's the point of using a regset.  You convert the 'g' packet output
>>>> > to a binary blob in the obvious way, and then that's your regset.  The
>>>> > target architecture supplies a regset that expects the format provided
>>>> > by the 'g' packet.  Is there some problem with that plan?
>>
>>> 
>>> No, regsets are perfect for 'g'.  I was thinking of the single-
>>> register case (all under the assumption that we'd like to restrict
>>> uses of supply_register and collect_register to regset functions).
>>> What do you do with, say, the individual registers from your fancy 'T'
>>> reply?
> 
> 
> I have no idea.  Good question.

(I've attached a few of comments that go with TARGET_OBJECT, check the 
archives for qPart)

For regsets, the ``void *buffer/long length'' pair can be replaced by a 
single ``byte array'' object.

The regset code can then send offset/length xfer requests to that ``byte 
array''.  For cores, the byte array would extract the bytes from the 
core file; for ptrace, the byte array would extract the bytes using the 
relevant ptrace call; and for the remote inferior, the request would be 
converted into one or more qPart packets (sending the 
regset/offset/length across the wire).

When it comes to a `T' reply, the remote inferior can push 
regset/offset/length data for parts of the regset buffer that it thinks 
are interesting.

>>> As far as I can tell, regsets don't serve this case well, which makes
>>> them (in their current state) less than suitable as a universal
>>> register transfer interface.

Andrew

/* Request the transfer of up to LEN 8-bit bytes of the target's
    OBJECT.  The OFFSET, for a seekable object, specifies the starting
    point.  The ANNEX can be used to provide additional data-specific
    information to the target.

    Return the number of bytes actually transfered, zero when no
    further transfer is possible, and -1 when the transfer is not
    supported.

    NOTE: cagney/2003-10-17: The current interface does not support a
    "retry" mechanism.  Instead it assumes that at least one byte will
    be transfered on each call.

    NOTE: cagney/2003-10-17: The current interface can lead to
    fragmented transfers.  Lower target levels should not implement
    hacks, such as enlarging the transfer, in an attempt to compensate
    for this.  Instead, the target stack should be extended so that it
    implements supply/collect methods and a look-aside object cache.
    With that available, the lowest target can safely and freely "push"
    data up the stack.

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Daniel Jacobowitz]

On Fri, Jul 02, 2004 at 11:39:41AM -0400, Andrew Cagney wrote:
> >On Thu, Jul 01, 2004 at 01:44:53PM -0500, Jim Blandy wrote:
> >
> >>>
> >>>Daniel Jacobowitz <drow@false.org> writes:
> >>
> >>>>> GDB won't have to know where to place their contents in the buffer!
> >>>>> That's the point of using a regset.  You convert the 'g' packet output
> >>>>> to a binary blob in the obvious way, and then that's your regset.  The
> >>>>> target architecture supplies a regset that expects the format provided
> >>>>> by the 'g' packet.  Is there some problem with that plan?
> >>
> >>>
> >>>No, regsets are perfect for 'g'.  I was thinking of the single-
> >>>register case (all under the assumption that we'd like to restrict
> >>>uses of supply_register and collect_register to regset functions).
> >>>What do you do with, say, the individual registers from your fancy 'T'
> >>>reply?
> >
> >
> >I have no idea.  Good question.
> 
> (I've attached a few of comments that go with TARGET_OBJECT, check the 
> archives for qPart)
> 
> For regsets, the ``void *buffer/long length'' pair can be replaced by a 
> single ``byte array'' object.
> 
> The regset code can then send offset/length xfer requests to that ``byte 
> array''.  For cores, the byte array would extract the bytes from the 
> core file; for ptrace, the byte array would extract the bytes using the 
> relevant ptrace call; and for the remote inferior, the request would be 
> converted into one or more qPart packets (sending the 
> regset/offset/length across the wire).
> 
> When it comes to a `T' reply, the remote inferior can push 
> regset/offset/length data for parts of the regset buffer that it thinks 
> are interesting.

If I'm interpreting your answer right, it is: "don't do anything about
it, change the remote protocol instead", right?

A more practical approach would probably be to maintain a mapping of
the remote protocol register numbers to GDB's internal register numbers
in addition to register sets.  I don't see any problem with that.

-- 
Daniel Jacobowitz

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Fri, Jul 02, 2004 at 11:39:41AM -0400, Andrew Cagney wrote:
> > >On Thu, Jul 01, 2004 at 01:44:53PM -0500, Jim Blandy wrote:
> > >
> > >>>
> > >>>Daniel Jacobowitz <drow@false.org> writes:
> > >>
> > >>>>> GDB won't have to know where to place their contents in the buffer!
> > >>>>> That's the point of using a regset.  You convert the 'g' packet output
> > >>>>> to a binary blob in the obvious way, and then that's your regset.  The
> > >>>>> target architecture supplies a regset that expects the format provided
> > >>>>> by the 'g' packet.  Is there some problem with that plan?
> > >>
> > >>>
> > >>>No, regsets are perfect for 'g'.  I was thinking of the single-
> > >>>register case (all under the assumption that we'd like to restrict
> > >>>uses of supply_register and collect_register to regset functions).
> > >>>What do you do with, say, the individual registers from your fancy 'T'
> > >>>reply?
> > >
> > >
> > >I have no idea.  Good question.
> > 
> > (I've attached a few of comments that go with TARGET_OBJECT, check the 
> > archives for qPart)
> > 
> > For regsets, the ``void *buffer/long length'' pair can be replaced by a 
> > single ``byte array'' object.
> > 
> > The regset code can then send offset/length xfer requests to that ``byte 
> > array''.  For cores, the byte array would extract the bytes from the 
> > core file; for ptrace, the byte array would extract the bytes using the 
> > relevant ptrace call; and for the remote inferior, the request would be 
> > converted into one or more qPart packets (sending the 
> > regset/offset/length across the wire).
> > 
> > When it comes to a `T' reply, the remote inferior can push 
> > regset/offset/length data for parts of the regset buffer that it thinks 
> > are interesting.
> 
> If I'm interpreting your answer right, it is: "don't do anything about
> it, change the remote protocol instead", right?
> 
> A more practical approach would probably be to maintain a mapping of
> the remote protocol register numbers to GDB's internal register numbers
> in addition to register sets.  I don't see any problem with that.

What if the remote protocol wants to talk about a 64-bit register, but
GDB's raw regcache sees that as two 32-bit registers?  A simple
number-to-number mapping doesn't do the trick.

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Daniel Jacobowitz]

On Tue, Jul 06, 2004 at 12:09:15PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@false.org> writes:
> > On Fri, Jul 02, 2004 at 11:39:41AM -0400, Andrew Cagney wrote:
> > > >On Thu, Jul 01, 2004 at 01:44:53PM -0500, Jim Blandy wrote:
> > > >
> > > >>>
> > > >>>Daniel Jacobowitz <drow@false.org> writes:
> > > >>
> > > >>>>> GDB won't have to know where to place their contents in the buffer!
> > > >>>>> That's the point of using a regset.  You convert the 'g' packet output
> > > >>>>> to a binary blob in the obvious way, and then that's your regset.  The
> > > >>>>> target architecture supplies a regset that expects the format provided
> > > >>>>> by the 'g' packet.  Is there some problem with that plan?
> > > >>
> > > >>>
> > > >>>No, regsets are perfect for 'g'.  I was thinking of the single-
> > > >>>register case (all under the assumption that we'd like to restrict
> > > >>>uses of supply_register and collect_register to regset functions).
> > > >>>What do you do with, say, the individual registers from your fancy 'T'
> > > >>>reply?
> > > >
> > > >
> > > >I have no idea.  Good question.
> > > 
> > > (I've attached a few of comments that go with TARGET_OBJECT, check the 
> > > archives for qPart)
> > > 
> > > For regsets, the ``void *buffer/long length'' pair can be replaced by a 
> > > single ``byte array'' object.
> > > 
> > > The regset code can then send offset/length xfer requests to that ``byte 
> > > array''.  For cores, the byte array would extract the bytes from the 
> > > core file; for ptrace, the byte array would extract the bytes using the 
> > > relevant ptrace call; and for the remote inferior, the request would be 
> > > converted into one or more qPart packets (sending the 
> > > regset/offset/length across the wire).
> > > 
> > > When it comes to a `T' reply, the remote inferior can push 
> > > regset/offset/length data for parts of the regset buffer that it thinks 
> > > are interesting.
> > 
> > If I'm interpreting your answer right, it is: "don't do anything about
> > it, change the remote protocol instead", right?
> > 
> > A more practical approach would probably be to maintain a mapping of
> > the remote protocol register numbers to GDB's internal register numbers
> > in addition to register sets.  I don't see any problem with that.
> 
> What if the remote protocol wants to talk about a 64-bit register, but
> GDB's raw regcache sees that as two 32-bit registers?  A simple
> number-to-number mapping doesn't do the trick.

Don't do that then.  Pass those as a regset, not numbered in the T
packet.  Or have the register renumbering function map that number to
the combined pseudo register!

-- 
Daniel Jacobowitz

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Jim Blandy]

Daniel Jacobowitz <drow@false.org> writes:
> On Tue, Jul 06, 2004 at 12:09:15PM -0500, Jim Blandy wrote:
> > Daniel Jacobowitz <drow@false.org> writes:
> > > A more practical approach would probably be to maintain a mapping of
> > > the remote protocol register numbers to GDB's internal register numbers
> > > in addition to register sets.  I don't see any problem with that.
> > 
> > What if the remote protocol wants to talk about a 64-bit register, but
> > GDB's raw regcache sees that as two 32-bit registers?  A simple
> > number-to-number mapping doesn't do the trick.
> 
> Don't do that then.  Pass those as a regset, not numbered in the T
> packet.

You're saying that, since we include register values in the T packet
just for expedience, we can always decline to do that when it's hard,
right?  But whether it's hard or not depends on GDB's raw regcache
layout, which isn't supposed to be a matter of public interface.  When
someone needs to rearrange the raw regcache, the set of registers
which can be profitably provided in a T packet changes.  That's not
the way it should be.

> Or have the register renumbering function map that number to the
> combined pseudo register!

But what would GDB's code handling that packet do with that pseudo-
register number?  It can't pass it to a regset or per-register
"supply" function.

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Daniel Jacobowitz]

On Thu, Jul 15, 2004 at 01:30:22PM -0500, Jim Blandy wrote:
> 
> Daniel Jacobowitz <drow@false.org> writes:
> > On Tue, Jul 06, 2004 at 12:09:15PM -0500, Jim Blandy wrote:
> > > Daniel Jacobowitz <drow@false.org> writes:
> > > > A more practical approach would probably be to maintain a mapping of
> > > > the remote protocol register numbers to GDB's internal register numbers
> > > > in addition to register sets.  I don't see any problem with that.
> > > 
> > > What if the remote protocol wants to talk about a 64-bit register, but
> > > GDB's raw regcache sees that as two 32-bit registers?  A simple
> > > number-to-number mapping doesn't do the trick.
> > 
> > Don't do that then.  Pass those as a regset, not numbered in the T
> > packet.
> 
> You're saying that, since we include register values in the T packet
> just for expedience, we can always decline to do that when it's hard,
> right?  But whether it's hard or not depends on GDB's raw regcache
> layout, which isn't supposed to be a matter of public interface.  When
> someone needs to rearrange the raw regcache, the set of registers
> which can be profitably provided in a T packet changes.  That's not
> the way it should be.
> 
> > Or have the register renumbering function map that number to the
> > combined pseudo register!
> 
> But what would GDB's code handling that packet do with that pseudo-
> register number?  It can't pass it to a regset or per-register
> "supply" function.

Then perhaps that should be changed.  In practice, many
pseudo-registers are suppliable.  It might even be possible to
rearrange the interfaces such that *_pseudo_register_write can be used,
via regcache_cooked_write, i.e. supply cooked registers.

This would require rethinking of the raw/cooked boundary.  Currently
the boundary is that raw registers are those we can query the target
for.  If you have a remote target that can not supply the same
registers we keep in the raw regcache, we have a design problem.

-- 
Daniel Jacobowitz

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Andrew Cagney]

>>> (I've attached a few of comments that go with TARGET_OBJECT, check the 
>>> archives for qPart)
>>> 
>>> For regsets, the ``void *buffer/long length'' pair can be replaced by a 
>>> single ``byte array'' object.
>>> 
>>> The regset code can then send offset/length xfer requests to that ``byte 
>>> array''.  For cores, the byte array would extract the bytes from the 
>>> core file; for ptrace, the byte array would extract the bytes using the 
>>> relevant ptrace call; and for the remote inferior, the request would be 
>>> converted into one or more qPart packets (sending the 
>>> regset/offset/length across the wire).
>>> 
>>> When it comes to a `T' reply, the remote inferior can push 
>>> regset/offset/length data for parts of the regset buffer that it thinks 
>>> are interesting.

> If I'm interpreting your answer right, it is: "don't do anything about
> it, change the remote protocol instead", right?

No.  But going forward we've got to dig our way out of the G/T packet 
bear trap.

> A more practical approach would probably be to maintain a mapping of
> the remote protocol register numbers to GDB's internal register numbers
> in addition to register sets.  I don't see any problem with that.

 From memory, the only thing missing is code to parse a regformats file.

Andrew

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Daniel Jacobowitz]

On Tue, Jul 06, 2004 at 01:42:54PM -0400, Andrew Cagney wrote:
> 
> >>>(I've attached a few of comments that go with TARGET_OBJECT, check the 
> >>>archives for qPart)
> >>>
> >>>For regsets, the ``void *buffer/long length'' pair can be replaced by a 
> >>>single ``byte array'' object.
> >>>
> >>>The regset code can then send offset/length xfer requests to that ``byte 
> >>>array''.  For cores, the byte array would extract the bytes from the 
> >>>core file; for ptrace, the byte array would extract the bytes using the 
> >>>relevant ptrace call; and for the remote inferior, the request would be 
> >>>converted into one or more qPart packets (sending the 
> >>>regset/offset/length across the wire).
> >>>
> >>>When it comes to a `T' reply, the remote inferior can push 
> >>>regset/offset/length data for parts of the regset buffer that it thinks 
> >>>are interesting.
> 
> >If I'm interpreting your answer right, it is: "don't do anything about
> >it, change the remote protocol instead", right?
> 
> No.  But going forward we've got to dig our way out of the G/T packet 
> bear trap.
> 
> >A more practical approach would probably be to maintain a mapping of
> >the remote protocol register numbers to GDB's internal register numbers
> >in addition to register sets.  I don't see any problem with that.
> 
> From memory, the only thing missing is code to parse a regformats file.

I did eventually intend for them to be used by the client.  I'll try to
find some round tuits.

-- 
Daniel Jacobowitz

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Andrew Cagney]

> At the moment, remote-sim.c's gdbsim_fetch_register and
> gdbsim_store_register functions assume that the simulator's register
> set (as visible via sim_fetch_register and sim_store_register)
> corresponds exactly to GDB's raw register set.  This patch is meant to
> remove that assumption.

Why do we need this extra level of indirection?  Since gdb/sim are 
paired at the source code level, we can simply change the gdb/sim interface.

Andrew

> 2004-06-30  Jim Blandy  <jimb@redhat.com>
> 
> 	Don't assume that the sim's register set and GDB's raw register
> 	set have the same layout.
> 	* gdbarch.sh (sim_supply_register, sim_collect_register): New
> 	methods.  Have gdbarch.c #include regcache.h.
> 	* gdbarch.c, gdbarch.h: Regenerate.
> 	* remote-sim.c (gdbsim_fetch_register): Pass the register value
> 	collected from the sim to GDB via the new gdbarch methods.
> 	* Makefile.in (gdbarch.o): Update dependencies.
> 

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Jim Blandy]

Andrew Cagney <cagney@gnu.org> writes:
> > At the moment, remote-sim.c's gdbsim_fetch_register and
> > gdbsim_store_register functions assume that the simulator's register
> > set (as visible via sim_fetch_register and sim_store_register)
> > corresponds exactly to GDB's raw register set.  This patch is meant to
> > remove that assumption.
> 
> Why do we need this extra level of indirection?  Since gdb/sim are
> paired at the source code level, we can simply change the gdb/sim
> interface.

You mean (in this case) just go in and tweak sim/ppc/sim_calls.c so
that the sim's register set (as viewed by sim_fetch_register and
sim_store_register) does match GDB's raw regcache?

It seems to me that one ought to be able to rearrange an
architecture's raw regcache without changing code outside the gdb
directory: it's supposed to be an internal interface.  If the
implementations of sim_* in the 'sim' subtree are considered internal
to GDB, then that seems like a misstructuring.

Re: RFA: make sim interface use gdbarch methods for collect/supply

[Andrew Cagney]

> Andrew Cagney <cagney@gnu.org> writes:
> 
>>>> > At the moment, remote-sim.c's gdbsim_fetch_register and
>>>> > gdbsim_store_register functions assume that the simulator's register
>>>> > set (as visible via sim_fetch_register and sim_store_register)
>>>> > corresponds exactly to GDB's raw register set.  This patch is meant to
>>>> > remove that assumption.
>>
>>> 
>>> Why do we need this extra level of indirection?  Since gdb/sim are
>>> paired at the source code level, we can simply change the gdb/sim
>>> interface.
> 
> 
> You mean (in this case) just go in and tweak sim/ppc/sim_calls.c so
> that the sim's register set (as viewed by sim_fetch_register and
> sim_store_register) does match GDB's raw regcache?

Yes, it lets us avoid an extra level of indirection and all the 
complexity it brings.  Lets do that, no point in adding a new interfaces 
when we can solve the problem by adjusting the old.

Andrew