Re: SH5 simulator contribution

[Joern Rennecke <joern dot rennecke at st dot com>]

ac131313@cygnus.com wrote:
> 
> > Andrew Cagney wrote:

> The SIM's register number and map change dependant on the configuration. 
> As a consequence GDB needs to exactly match its self with the 
> simulator's internal register schema instead of a standard well-defined 
> register map.  I don't think this exactly lends its self to a 
> maintainable situtation.

The old (sh1/sh2/sh2-dsp/sh3e/sh3-dsp/sh4) simulator already does a
translation between the gdb interface and its internal register numbering
in sim_fetch_register / sim_store_register; I introduced this when indeed I
changed the simulator's internal register schema.

The new (sh2/sh3/sh3e/sh4/sh5) simulator uses the defines in include/sim-sh64.h
in its sh64_fetch_register sh64_store_register to translate to its internal
register accessor functions.

> > You can't just change the numbering in the interface between gcc and gdb,
> > because that would break binary compatibility.  And you also can't change
> > the interface between gdb and hardware monitors.
> 
> Strictly speaking GCC does re-number the interface between GCC and GDB.
>   .stabs and dwarf2 debug info can have different register numbering for
> the same ISA/ABI.  Fortunatly GDB has mechanisms for handling this.
> 
> As for hardware monitors, I'm not sure.  I do know that the MIPS has
> more G packet formats than I've had hot dinners.  Here, unfortunatly,
> the mechanisms GDB needed to handle this are still work-in-progress.

We already have an sh-elf port with dwarf debugging information that uses
the old interface.  We should keep with that interface for the ABIs it
has been in use for, i.e. sh1/sh2,sh2-dsp,sh3,sh3e and sh4, to avoid
unnecessary binary incompatibilites and tool version incompatibilities.

The sh5 abi does not only use a larger set of registers - including a
larger set of general purpose and floatin point registers -  but also uses
existing ones in wider sizes, so it makes sense to use a different interface
for it.
	
> As for the SIM, there is REGISTER_SIM_REGNO.  However, that may not be
> sufficient.

My concern is not so much with the implementation of extra translations as
that we are making things unnecessarily complicated by having a different
interface to the simulator than the to gcc and the hardware monitors, and
having a switch date when interfaces in gdb and the simulator change.
And you would still have to change the register sizes.  
	
> > So I don't see that you gain anything by unifying the numbering scheme
> > in the gdb <-> sim interface, as it would be at odds with the interface
> > to gcc and the hardware interfaces.
> 
> Formalizing would be a better word.  So that GDB and the SIM can agree
> on the register numbers and their sizes without needing to know the
> others internals.

They only need to know if the program is for an sh5 or an earlier processor.
This information is readily available from the elf flags (the lower five bits
of which enconde the sh version this program is compiled for), or the bfd
word size.  Gdb already needs to know this in order to print registers in the
correct size, and the simulator in order to simulate the right instruction
set(s).

So do you want a file that explicitly documents the two interface?
The danger of this is that if registers are added to a successor of the sh5,
the documentation can get out-of-sync with the header file.

Or should we rather make an include/sim-sh.h file - to be used in the old
simulators sim_fetch_register / sim_store_register as well as in the
to-be-written translation function in the new simulator for sh2-sh4 programs,
and state in gdbint.texi that the interfaces are defined in include/sim-sh.h
and include/sim-sh64.h ?
		
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330