SH5 simulator contribution

SH5 simulator contribution

[Ben Elliston]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 418 bytes --]

I would like to contribute the Hitachi SH5 simulator (sh64).  The
patches appear below.  Can this please be accepted into the FSF GDB
distribution?

I have already made the requisite changes to the FSF master copy of
config.sub.  Shall I import the latest version?

Ben


[dejagnu/ChangeLog]

2002-02-02  Ben Elliston  <bje@redhat.com>
	    Alexandre Oliva  <aoliva@redhat.com>

	* baseboards/sh64-sim.exp: New file.


[-- Attachment #2: sh64-sim.exp --]
[-- Type: application/octet-stream, Size: 1507 bytes --]

# This is a list of toolchains that are supported on this board.
set_board_info target_install {sh64-elf}

# Load the generic configuration for this board. This will define a basic set
# of routines needed by the tool to communicate with the board.
load_generic_config "sim"

# basic-sim.exp is a basic description for the standard Cygnus simulator.
load_base_board_description "basic-sim"

# "sh64" is the name of the sim subdir in devo/sim.
setup_sim sh64

# No multilib options needed by default.
process_multilib_options ""

# We only support newlib on this target. We assume that all multilib
# options have been specified before we get here.

set_board_info compiler  "[find_gcc]"
set_board_info cflags    "[libgloss_include_flags] [newlib_include_flags]"
set_board_info ldflags   "[libgloss_link_flags] [newlib_link_flags]"
# No linker script needed.
set_board_info ldscript "";

# Used by a few gcc.c-torture testcases to delimit how large the stack can
# be.
set_board_info gcc,stack_size  0x20000

# Need to pass -mieee in order to for the compiler to be IEEE-fp compliant.
set_board_info ieee_multilib_flags "-mieee";

# The simulator doesn't return exit statuses and we need to indicate this;
# the standard GCC wrapper will work with this target.
set_board_info needs_status_wrapper  1
# Doesn't pass arguments or signals, can't return results, and doesn't
# do inferiorio.
set_board_info noargs 1
set_board_info gdb,nosignals 1
set_board_info gdb,noresults 1
set_board_info gdb,noinferiorio 1

[-- Attachment #3: message body text --]
[-- Type: text/plain, Size: 98 bytes --]


[include/ChangeLog]

2002-02-02  Elena Zannoni  <ezannoni@redhat.com>

	* sim-sh64.h: New file.


[-- Attachment #4: sim-sh64.h --]
[-- Type: application/octet-stream, Size: 1597 bytes --]

/* This file defines the interface between the sh64 simulator and gdb.
   Copyright (C) 2000 Free Software Foundation, Inc.

This file is part of GDB.

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */

#if !defined (SIM_SH64_H)
#define SIM_SH64_H

#ifdef __cplusplus
extern "C" { // }
#endif

/* The simulator makes use of the following register information. */

enum
  {
    SIM_SH64_R0_REGNUM = 0,
    SIM_SH64_SP_REGNUM = 15,
    SIM_SH64_PC_REGNUM = 64,
    SIM_SH64_SR_REGNUM = 65,
    SIM_SH64_SSR_REGNUM = 66,
    SIM_SH64_SPC_REGNUM = 67,
    SIM_SH64_TR0_REGNUM = 68,
    SIM_SH64_FPCSR_REGNUM = 76,
    SIM_SH64_FR0_REGNUM = 77
  };

enum
  {
    SIM_SH64_NR_REGS = 141,  /* total number of architectural registers */
    SIM_SH64_NR_R_REGS = 64, /* number of general registers */
    SIM_SH64_NR_TR_REGS = 8, /* number of target registers */
    SIM_SH64_NR_FP_REGS = 64 /* number of floating point registers */
  };

#ifdef __cplusplus
}
#endif

#endif

[-- Attachment #5: message body text --]
[-- Type: text/plain, Size: 742 bytes --]


[sim/ChangeLog]

2002-02-02  Ben Elliston  <bje@redhat.com>

        * configure.in: Add support for sh64.
        * configure: Regenerate.

Index: configure.in
===================================================================
RCS file: /cvs/src/src/sim/configure.in,v
retrieving revision 1.8
diff -u -c -r1.8 configure.in
*** configure.in	2002/02/02 04:48:32	1.8
--- configure.in	2002/02/02 10:01:09
***************
*** 86,91 ****
--- 86,95 ----
    mn10200*-*-*)
  	sim_target=mn10200
  	;;
+   sh64-*-*)
+ 	sim_target=sh64
+ 	extra_subdirs="${extra_subdirs} testsuite"
+ 	;;
    sh*-*-*)		sim_target=sh ;;
    powerpc*-*-eabi* | powerpc*-*-solaris* | powerpc*-*-sysv4* | \
    powerpc*-*-elf* | powerpc*-*-linux* | powerpc*-*-netbsd* )

Re: SH5 simulator contribution

[Andrew Cagney]

> I would like to contribute the Hitachi SH5 simulator (sh64).  The
> patches appear below.  Can this please be accepted into the FSF GDB
> distribution?


(and the simulator code?)

This is significant and hopefully a good thing.  The old sh simulator is 
legendary, in some circles for, probably, all the wrong reaons.  Still 
two questions.

Firstly, GDB already has an SH simululator that can be used to generate 
a sh1, sh2, sh3, sh3e, sh4 and sh-dsp (but only one at a time).  Does 
this new simulator cover that set or only a subset?  i.e. is it a drop 
in replacement?

Secondly, the MIPS, mn10300, d10v and other IGEN simulators support more 
than one cpu variant (can't use ISA - see binutils list :-/).  How does 
this simulator go in this regard?


> I have already made the requisite changes to the FSF master copy of
> config.sub.  Shall I import the latest version?


Anyone can do that anytime.  See src/MAINTAINERS for the process.

enjoy,
Andrew

Re: SH5 simulator contribution

[Ben Elliston]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

  Andrew> Firstly, GDB already has an SH simululator that can be used to generate 
  Andrew> a sh1, sh2, sh3, sh3e, sh4 and sh-dsp (but only one at a time).  Does 
  Andrew> this new simulator cover that set or only a subset?  i.e. is it a drop 
  Andrew> in replacement?

It covers a subset.  It will handle sh2, sh3, sh4 and sh5.  In other
words, it is not (quite) yet able to replace the existing SH[1-4]
simulator.

  Andrew> Secondly, the MIPS, mn10300, d10v and other IGEN simulators support more 
  Andrew> than one cpu variant (can't use ISA - see binutils list :-/).  How does 
  Andrew> this simulator go in this regard?

I'm afraid I'm going to need you to clarify the terminology.  :-(

Ben

Re: SH5 simulator contribution

[Andrew Cagney]

> It covers a subset.  It will handle sh2, sh3, sh4 and sh5.  In other
> words, it is not (quite) yet able to replace the existing SH[1-4]
> simulator.
> 
>   Andrew> Secondly, the MIPS, mn10300, d10v and other IGEN simulators support more 
>   Andrew> than one cpu variant (can't use ISA - see binutils list :-/).  How does 
>   Andrew> this simulator go in this regard?
> 
> I'm afraid I'm going to need you to clarify the terminology.  :-(


The mn10300 simulator binary, contains a simulator for both

:model:::mn10300:mn10300:
:model:::am33:am33:


Which simulator to use being selected at run time.  The other two are 
v850 and MIPS (not d10v).   This jells well with GDB which also supports 
  those same architecture variants.

Andrew

Re: SH5 simulator contribution

[Ben Elliston]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

  Andrew> The mn10300 simulator binary, contains a simulator for both

  Andrew> :model:::mn10300:mn10300:
  Andrew> :model:::am33:am33:

  Andrew> Which simulator to use being selected at run time.  The other two are 
  Andrew> v850 and MIPS (not d10v).   This jells well with GDB which also supports 
  Andrew>   those same architecture variants.

This could certainly be done.  There is only one cpu variant right now
("sh5").

Ben

Re: SH5 simulator contribution

[Andrew Cagney]

> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> 
> 
> Andrew> The mn10300 simulator binary, contains a simulator for both
> 
>   Andrew> :model:::mn10300:mn10300:
>   Andrew> :model:::am33:am33:
> 
>   Andrew> Which simulator to use being selected at run time.  The other two are 
>   Andrew> v850 and MIPS (not d10v).   This jells well with GDB which also supports 
>   Andrew> those same architecture variants.
> 
> This could certainly be done.  There is only one cpu variant right now
> ("sh5").


That would be very useful.  This means that when you say it supports the

sh2..sh4 it is through the backward compatibility of the instruction set

architecture. This explains why the config tweeks only enable the

simulator when sh64-elf.


If I understand the sim/sh simulator correctly, it currently generates 
an sh-dsp sim which is backward compatible with sh2-4 (sh1?) but not 
with sh5.  This means that the new sh5 simulator is not a drop in 
replacement for the existing simulator (it lacks sh-dsp).

Unless the new simulator gains sh-dsp support, the sim directory will 
need to be configurable so that the user can select either the DSP xor 
the SH5 simulator.  That, I suspect, is going to get messy.  I think GDB 
should be able to assume a single SH remote-sim interface but here, I 
suspect, it is currently contending with two different interfaces :-(

Andrew

Re: SH5 simulator contribution

[Ben Elliston]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:

  Andrew> That would be very useful.  This means that when you say it supports the
  Andrew> sh2..sh4 it is through the backward compatibility of the instruction set
  Andrew> architecture. This explains why the config tweeks only enable the
  Andrew> simulator when sh64-elf.

Correct.

  Andrew> If I understand the sim/sh simulator correctly, it currently generates 
  Andrew> an sh-dsp sim which is backward compatible with sh2-4 (sh1?) but not 
  Andrew> with sh5.  This means that the new sh5 simulator is not a drop in 
  Andrew> replacement for the existing simulator (it lacks sh-dsp).

Also correct.

  Andrew> Unless the new simulator gains sh-dsp support, the sim directory will 
  Andrew> need to be configurable so that the user can select either the DSP xor 
  Andrew> the SH5 simulator.  That, I suspect, is going to get messy.  I think GDB 
  Andrew> should be able to assume a single SH remote-sim interface but here, I 
  Andrew> suspect, it is currently contending with two different interfaces :-(

Hence, this is why the sh5 sim is only configured when the target is
sh64-*-elf.

Ben

Re: SH5 simulator contribution

[Andrew Cagney]

>  Andrew> Unless the new simulator gains sh-dsp support, the sim directory will 
>   Andrew> need to be configurable so that the user can select either the DSP xor 
>   Andrew> the SH5 simulator.  That, I suspect, is going to get messy.  I think GDB 
>   Andrew> should be able to assume a single SH remote-sim interface but here, I 
>   Andrew> suspect, it is currently contending with two different interfaces :-(
> 
> Hence, this is why the sh5 sim is only configured when the target is
> sh64-*-elf.


Er, humor me.

The sim/sh simulator has a specific register name / number / size 
mapping and sh-elf-gdb knows how to use it.

This new sim/sh5 simulator has a different register / name / size 
mapping and this difference is covered up by GDB.  (I note the addition 
of the sim-sh64.h file which is in itself a very good move).

The MIPS (unintentionally) went down this path and ever since the MIPS 
has been trying to claw its way out of the resultant mess :-(  Given 
this, I think it would be better to just eliminate one of the 
simulators.  Failing that, ensure that at least the two simulators 
complied to an identical register name/number/size interface.

Would it possible to get this new SH simulator to support the sh-dsp 
instructions (there can't be that many of them) so that the old 
simulator can be retired?

More as a wish list, would it also be possible to have separate but 
integrated simulators for at least the few most recent SH variants - 
like mn10300 and am33.  I suspect this simulator was generated so it 
shouldn't be too hard.

Andrew

Re: SH5 simulator contribution

[Joern Rennecke]

Andrew Cagney wrote:
> The sim/sh simulator has a specific register name / number / size 
> mapping and sh-elf-gdb knows how to use it.
> 
> This new sim/sh5 simulator has a different register / name / size 
> mapping and this difference is covered up by GDB.  (I note the addition 
> of the sim-sh64.h file which is in itself a very good move).

Actually, the difference is not covered up by gdb.  The compiler emits
different register numbers when compiling for sh5 or shcompact than
when compiling for sh1..sh4.
The sh64 simulator matches the numbering scheme for the sh5 / shcompact
targets, while the old sh simulator matches the numbering scheme for
sh1..sh4 targets.  When you try to use gdb with the sh64 simulator
as submitted so far on an sh4 program (i.e. set a breakpoint, display
registers), it just falls over.

In order to have a unified interface between gdb and the simulator, you
would have first to introduce a translation step in gdb to translate the
old register numbers for sh1..sh4 programs to the new scheme, and in the
old simulator translate it back (the latter is easy, since there is
already a translation going on in sim_store_register / sim_fetch_register).

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.
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.

> The MIPS (unintentionally) went down this path and ever since the MIPS 
> has been trying to claw its way out of the resultant mess :-(  Given 

Could you be more specific what you are trying to avoid?

> this, I think it would be better to just eliminate one of the 
> simulators.  Failing that, ensure that at least the two simulators 
> complied to an identical register name/number/size interface.
> 
> Would it possible to get this new SH simulator to support the sh-dsp 
> instructions (there can't be that many of them) so that the old 
> simulator can be retired?

It's not so much the number of sh-dsp instructions - although it's
a pretty large one, there is special code in the simulator sources
to automatically generate the descriptions from a smaller number of
templates - but the fact that they are of variable length, and use
three different address spaces.  I understand that cgen would need
some non-trivial infrastructure work to handle this.

The new simulator also has no SH1 support, although that should be
comparatively simple to add.

> More as a wish list, would it also be possible to have separate but 
> integrated simulators for at least the few most recent SH variants - 
> like mn10300 and am33.  I suspect this simulator was generated so it 
> shouldn't be too hard.

SH4 and SH5 are the most recently released SH variants.  So if the new
simulator could be fixed to handle debugging of sh4 programs - I hope that
is just adding some code to set CPU_REG_FETCH and CPU_REG_STORE to
sensible values for sh4 (and sh2,sh3,sh3e), i.e. put something new
instead of shcompact_init_cpu into sh4_mach - than this goal would be
fulfilled.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 simulator contribution

[Joern Rennecke]

Andrew Cagney wrote:
> The sim/sh simulator has a specific register name / number / size 
> mapping and sh-elf-gdb knows how to use it.
> 
> This new sim/sh5 simulator has a different register / name / size 
> mapping and this difference is covered up by GDB.  (I note the addition 
> of the sim-sh64.h file which is in itself a very good move).

Actually, the difference is not covered up by gdb.  The compiler emits
different register numbers when compiling for sh5 or shcompact than
when compiling for sh1..sh4.
The sh64 simulator matches the numbering scheme for the sh5 / shcompact
targets, while the old sh simulator matches the numbering scheme for
sh1..sh4 targets.  When you try to use gdb with the sh64 simulator
as submitted so far on an sh4 program (i.e. set a breakpoint, display
registers), it just falls over.

In order to have a unified interface between gdb and the simulator, you
would have first to introduce a translation step in gdb to translate the
old register numbers for sh1..sh4 programs to the new scheme, and in the
old simulator translate it back (the latter is easy, since there is
already a translation going on in sim_store_register / sim_fetch_register).

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.
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.

> The MIPS (unintentionally) went down this path and ever since the MIPS 
> has been trying to claw its way out of the resultant mess :-(  Given 

Could you be more specific what you are trying to avoid?

> this, I think it would be better to just eliminate one of the 
> simulators.  Failing that, ensure that at least the two simulators 
> complied to an identical register name/number/size interface.
> 
> Would it possible to get this new SH simulator to support the sh-dsp 
> instructions (there can't be that many of them) so that the old 
> simulator can be retired?

It's not so much the number of sh-dsp instructions - although it's
a pretty large one, there is special code in the simulator sources
to automatically generate the descriptions from a smaller number of
templates - but the fact that they are of variable length, and use
three different address spaces.  I understand that cgen would need
some non-trivial infrastructure work to handle this.

The new simulator also has no SH1 support, although that should be
comparatively simple to add.

> More as a wish list, would it also be possible to have separate but 
> integrated simulators for at least the few most recent SH variants - 
> like mn10300 and am33.  I suspect this simulator was generated so it 
> shouldn't be too hard.

SH4 and SH5 are the most recently released SH variants.  So if the new
simulator could be fixed to handle debugging of sh4 programs - I hope that
is just adding some code to set CPU_REG_FETCH and CPU_REG_STORE to
sensible values for sh4 (and sh2,sh3,sh3e), i.e. put something new
instead of shcompact_init_cpu into sh4_mach - than this goal would be
fulfilled.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 simulator contribution

[Joern Rennecke]

Andrew Cagney wrote:
> The sim/sh simulator has a specific register name / number / size 
> mapping and sh-elf-gdb knows how to use it.
> 
> This new sim/sh5 simulator has a different register / name / size 
> mapping and this difference is covered up by GDB.  (I note the addition 
> of the sim-sh64.h file which is in itself a very good move).

Actually, the difference is not covered up by gdb.  The compiler emits
different register numbers when compiling for sh5 or shcompact than
when compiling for sh1..sh4.
The sh64 simulator matches the numbering scheme for the sh5 / shcompact
targets, while the old sh simulator matches the numbering scheme for
sh1..sh4 targets.  When you try to use gdb with the sh64 simulator
as submitted so far on an sh4 program (i.e. set a breakpoint, display
registers), it just falls over.

In order to have a unified interface between gdb and the simulator, you
would have first to introduce a translation step in gdb to translate the
old register numbers for sh1..sh4 programs to the new scheme, and in the
old simulator translate it back (the latter is easy, since there is
already a translation going on in sim_store_register / sim_fetch_register).

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.
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.

> The MIPS (unintentionally) went down this path and ever since the MIPS 
> has been trying to claw its way out of the resultant mess :-(  Given 

Could you be more specific what you are trying to avoid?

> this, I think it would be better to just eliminate one of the 
> simulators.  Failing that, ensure that at least the two simulators 
> complied to an identical register name/number/size interface.
> 
> Would it possible to get this new SH simulator to support the sh-dsp 
> instructions (there can't be that many of them) so that the old 
> simulator can be retired?

It's not so much the number of sh-dsp instructions - although it's
a pretty large one, there is special code in the simulator sources
to automatically generate the descriptions from a smaller number of
templates - but the fact that they are of variable length, and use
three different address spaces.  I understand that cgen would need
some non-trivial infrastructure work to handle this.

The new simulator also has no SH1 support, although that should be
comparatively simple to add.

> More as a wish list, would it also be possible to have separate but 
> integrated simulators for at least the few most recent SH variants - 
> like mn10300 and am33.  I suspect this simulator was generated so it 
> shouldn't be too hard.

SH4 and SH5 are the most recently released SH variants.  So if the new
simulator could be fixed to handle debugging of sh4 programs - I hope that
is just adding some code to set CPU_REG_FETCH and CPU_REG_STORE to
sensible values for sh4 (and sh2,sh3,sh3e), i.e. put something new
instead of shcompact_init_cpu into sh4_mach - than this goal would be
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 simulator contribution

[Joern Rennecke]

Andrew Cagney wrote:
> The sim/sh simulator has a specific register name / number / size 
> mapping and sh-elf-gdb knows how to use it.
> 
> This new sim/sh5 simulator has a different register / name / size 
> mapping and this difference is covered up by GDB.  (I note the addition 
> of the sim-sh64.h file which is in itself a very good move).

Actually, the difference is not covered up by gdb.  The compiler emits
different register numbers when compiling for sh5 or shcompact than
when compiling for sh1..sh4.
The sh64 simulator matches the numbering scheme for the sh5 / shcompact
targets, while the old sh simulator matches the numbering scheme for
sh1..sh4 targets.  When you try to use gdb with the sh64 simulator
as submitted so far on an sh4 program (i.e. set a breakpoint, display
registers), it just falls over.

In order to have a unified interface between gdb and the simulator, you
would have first to introduce a translation step in gdb to translate the
old register numbers for sh1..sh4 programs to the new scheme, and in the
old simulator translate it back (the latter is easy, since there is
already a translation going on in sim_store_register / sim_fetch_register).

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.
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.

> The MIPS (unintentionally) went down this path and ever since the MIPS 
> has been trying to claw its way out of the resultant mess :-(  Given 

Could you be more specific what you are trying to avoid?

> this, I think it would be better to just eliminate one of the 
> simulators.  Failing that, ensure that at least the two simulators 
> complied to an identical register name/number/size interface.
> 
> Would it possible to get this new SH simulator to support the sh-dsp 
> instructions (there can't be that many of them) so that the old 
> simulator can be retired?

It's not so much the number of sh-dsp instructions - although it's
a pretty large one, there is special code in the simulator sources
to automatically generate the descriptions from a smaller number of
templates - but the fact that they are of variable length, and use
three different address spaces.  I understand that cgen would need
some non-trivial infrastructure work to handle this.

The new simulator also has no SH1 support, although that should be
comparatively simple to add.

> More as a wish list, would it also be possible to have separate but 
> integrated simulators for at least the few most recent SH variants - 
> like mn10300 and am33.  I suspect this simulator was generated so it 
> shouldn't be too hard.

SH4 and SH5 are the most recently released SH variants.  So if the new
simulator could be fixed to handle debugging of sh4 programs - I hope that
is just adding some code to set CPU_REG_FETCH and CPU_REG_STORE to
sensible values for sh4 (and sh2,sh3,sh3e), i.e. put something new
instead of shcompact_init_cpu into sh4_mach - than this goal would be
fulfilled.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 simulator contribution

[Joern Rennecke]

Andrew Cagney wrote:
> The sim/sh simulator has a specific register name / number / size 
> mapping and sh-elf-gdb knows how to use it.
> 
> This new sim/sh5 simulator has a different register / name / size 
> mapping and this difference is covered up by GDB.  (I note the addition 
> of the sim-sh64.h file which is in itself a very good move).

Actually, the difference is not covered up by gdb.  The compiler emits
different register numbers when compiling for sh5 or shcompact than
when compiling for sh1..sh4.
The sh64 simulator matches the numbering scheme for the sh5 / shcompact
targets, while the old sh simulator matches the numbering scheme for
sh1..sh4 targets.  When you try to use gdb with the sh64 simulator
as submitted so far on an sh4 program (i.e. set a breakpoint, display
registers), it just falls over.

In order to have a unified interface between gdb and the simulator, you
would have first to introduce a translation step in gdb to translate the
old register numbers for sh1..sh4 programs to the new scheme, and in the
old simulator translate it back (the latter is easy, since there is
already a translation going on in sim_store_register / sim_fetch_register).

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.
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.

> The MIPS (unintentionally) went down this path and ever since the MIPS 
> has been trying to claw its way out of the resultant mess :-(  Given 

Could you be more specific what you are trying to avoid?

> this, I think it would be better to just eliminate one of the 
> simulators.  Failing that, ensure that at least the two simulators 
> complied to an identical register name/number/size interface.
> 
> Would it possible to get this new SH simulator to support the sh-dsp 
> instructions (there can't be that many of them) so that the old 
> simulator can be retired?

It's not so much the number of sh-dsp instructions - although it's
a pretty large one, there is special code in the simulator sources
to automatically generate the descriptions from a smaller number of
templates - but the fact that they are of variable length, and use
three different address spaces.  I understand that cgen would need
some non-trivial infrastructure work to handle this.

The new simulator also has no SH1 support, although that should be
comparatively simple to add.

> More as a wish list, would it also be possible to have separate but 
> integrated simulators for at least the few most recent SH variants - 
> like mn10300 and am33.  I suspect this simulator was generated so it 
> shouldn't be too hard.

SH4 and SH5 are the most recently released SH variants.  So if the new
simulator could be fixed to handle debugging of sh4 programs - I hope that
is just adding some code to set CPU_REG_FETCH and CPU_REG_STORE to
sensible values for sh4 (and sh2,sh3,sh3e), i.e. put something new
instead of shcompact_init_cpu into sh4_mach - than this goal would be
fulfilled.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 simulator contribution

[Joern Rennecke]

Andrew Cagney wrote:
> The sim/sh simulator has a specific register name / number / size 
> mapping and sh-elf-gdb knows how to use it.
> 
> This new sim/sh5 simulator has a different register / name / size 
> mapping and this difference is covered up by GDB.  (I note the addition 
> of the sim-sh64.h file which is in itself a very good move).

Actually, the difference is not covered up by gdb.  The compiler emits
different register numbers when compiling for sh5 or shcompact than
when compiling for sh1..sh4.
The sh64 simulator matches the numbering scheme for the sh5 / shcompact
targets, while the old sh simulator matches the numbering scheme for
sh1..sh4 targets.  When you try to use gdb with the sh64 simulator
as submitted so far on an sh4 program (i.e. set a breakpoint, display
registers), it just falls over.

In order to have a unified interface between gdb and the simulator, you
would have first to introduce a translation step in gdb to translate the
old register numbers for sh1..sh4 programs to the new scheme, and in the
old simulator translate it back (the latter is easy, since there is
already a translation going on in sim_store_register / sim_fetch_register).

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.
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.

> The MIPS (unintentionally) went down this path and ever since the MIPS 
> has been trying to claw its way out of the resultant mess :-(  Given 

Could you be more specific what you are trying to avoid?

> this, I think it would be better to just eliminate one of the 
> simulators.  Failing that, ensure that at least the two simulators 
> complied to an identical register name/number/size interface.
> 
> Would it possible to get this new SH simulator to support the sh-dsp 
> instructions (there can't be that many of them) so that the old 
> simulator can be retired?

It's not so much the number of sh-dsp instructions - although it's
a pretty large one, there is special code in the simulator sources
to automatically generate the descriptions from a smaller number of
templates - but the fact that they are of variable length, and use
three different address spaces.  I understand that cgen would need
some non-trivial infrastructure work to handle this.

The new simulator also has no SH1 support, although that should be
comparatively simple to add.

> More as a wish list, would it also be possible to have separate but 
> integrated simulators for at least the few most recent SH variants - 
> like mn10300 and am33.  I suspect this simulator was generated so it 
> shouldn't be too hard.

SH4 and SH5 are the most recently released SH variants.  So if the new
simulator could be fixed to handle debugging of sh4 programs - I hope that
is just adding some code to set CPU_REG_FETCH and CPU_REG_STORE to
sensible values for sh4 (and sh2,sh3,sh3e), i.e. put something new
instead of shcompact_init_cpu into sh4_mach - than this goal would be
fulfilled.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 simulator contribution

[Andrew Cagney]

> The MIPS (unintentionally) went down this path and ever since the MIPS 
>> has been trying to claw its way out of the resultant mess :-(  Given 
> 
> 
> Could you be more specific what you are trying to avoid?

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.

Instead there should be a standard map (as with the d10v) and both sides 
use that.

Andrew

Re: SH5 simulator contribution

[Andrew Cagney]

> Andrew Cagney wrote:
> 
>> The sim/sh simulator has a specific register name / number / size 
>> mapping and sh-elf-gdb knows how to use it.
>> 
>> This new sim/sh5 simulator has a different register / name / size 
>> mapping and this difference is covered up by GDB.  (I note the addition 
>> of the sim-sh64.h file which is in itself a very good move).
> 
> 
> Actually, the difference is not covered up by gdb.  The compiler emits
> different register numbers when compiling for sh5 or shcompact than
> when compiling for sh1..sh4.
> The sh64 simulator matches the numbering scheme for the sh5 / shcompact
> targets, while the old sh simulator matches the numbering scheme for
> sh1..sh4 targets.  When you try to use gdb with the sh64 simulator
> as submitted so far on an sh4 program (i.e. set a breakpoint, display
> registers), it just falls over.

Until the sim works, GDB probably won't add the code :-)  The 
infrastructure is there.

> In order to have a unified interface between gdb and the simulator, you
> would have first to introduce a translation step in gdb to translate the
> old register numbers for sh1..sh4 programs to the new scheme, and in the
> old simulator translate it back (the latter is easy, since there is
> already a translation going on in sim_store_register / sim_fetch_register).


> 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.

As for the SIM, there is REGISTER_SIM_REGNO.  However, that may not be 
sufficient.

> 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.

Andrew

Re: SH5 simulator contribution

[Joern Rennecke]

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

Re: SH5 simulator contribution

[Andrew Cagney]

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

Yes?

> 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.

Sorry, you've lost me here.  There should be only one GDB:SIM interface 
for the SH.

> 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 ?

Having just looked at a different target (similar problem), I think 
having a single file that assigns different number ranges to the sh4 vs 
sh64 registers would be best.  That would make it easy to detect things 
like trying to fetch an SH64 register from the SH4 sim.

Andrew

Re: SH5 simulator contribution

[Joern Rennecke]

ac131313@cygnus.com wrote:
> 
> > 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
> Having just looked at a different target (similar problem), I think
> having a single file that assigns different number ranges to the sh4 vs
> sh64 registers would be best.  That would make it easy to detect things
> like trying to fetch an SH64 register from the SH4 sim.

Using the current raw / pseudo-register distinction, that would lead to funny
artifacts: the sh and sh64 raw registers would all come first, and only then
the can the pseudo registers follow.

In regcache.c:fetch_register / store_register, you added this comment:

   /* NOTE: cagney/2001-12-04: Legacy targets were using fetch/store
     pseudo-register as a way of handling registers that needed to be
     constructed from one or more raw registers.  New targets instead
     use gdbarch register read/write.  */

I suppose I could handle all the pseudos in sim_fetch_register /
sim_store_register,
but then the hardware interfaces would break.

So maybe for the pre-sh5 targets, we should continue to use a relatively low
raw register threshold so that the pseudo registers can immediately follow;
The sh64 simulator can use a higher threshold that makes the sh4 pseudos into
registers that are read/stored with sim_read_register / sim_store_register,
i.e. eventuially via sh64_fetch_register / sh64_store_register.
Then the sh1..sh4 register numbers can be used for the compact registers, too.

	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330

Re: SH5 simulator contribution

[Andrew Cagney]

>> >> 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
> 
>> Having just looked at a different target (similar problem), I think
>> having a single file that assigns different number ranges to the sh4 vs
>> sh64 registers would be best.  That would make it easy to detect things
>> like trying to fetch an SH64 register from the SH4 sim.
> 
> 
> Using the current raw / pseudo-register distinction, that would lead to funny
> artifacts: the sh and sh64 raw registers would all come first, and only then
> the can the pseudo registers follow.

Um, these sim register numbers are separate to GDB's internal ``raw'' 
registers (and don't have anything to do with pseudo-registers).  GDB 
will need to map any internal register number onto the published sim 
register number before fetching a sim register.

Given an enum

	sim_sh_regnum {
	... sim_sh64_r0, ...sim_sh_r0, ...
	}

(who knows if r0 exists on the sh).  If GDB thinks it is talking to an 
sh64 sim it would ask for ``sim_sh64_r0'', on the other hand if it 
things it is talking to an SH4 or prior, it would ask for sim_sh_r0.

If GDB and SIM think differently (one is sh64 and the other is SH) then, 
I think, the only immediate objective is to not dump core.

Andrew

Re: SH5 simulator contribution

[Joern Rennecke]

ac131313@cygnus.com wrote:
> Um, these sim register numbers are separate to GDB's internal ``raw''
> registers (and don't have anything to do with pseudo-registers).  GDB
> will need to map any internal register number onto the published sim
> register number before fetching a sim register.

Yes, I understand that.  For the SH, sets of two single-precision
registers can be referred to as a double precision register, and sets
of four can be referred to as a vector. 

> If GDB and SIM think differently (one is sh64 and the other is SH) then,
> I think, the only immediate objective is to not dump core.

That'd be all right then.  sh gdb & sh64 sim: compatible for user mode programs.
sh64 gdb & sh sim: registers will be detected as out of range.
	
-- 
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330