This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


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

Re: SH5 simulator contribution


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


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