* Re: SH5 simulator contribution
2002-02-05 17:36 ` Andrew Cagney
@ 2002-04-12 2:46 ` Joern Rennecke
2002-04-12 9:30 ` Andrew Cagney
2002-04-12 9:45 ` Andrew Cagney
2002-04-12 2:48 ` Joern Rennecke
` (4 subsequent siblings)
5 siblings, 2 replies; 21+ messages in thread
From: Joern Rennecke @ 2002-04-12 2:46 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Ben Elliston, gdb-patches
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: SH5 simulator contribution
2002-04-12 2:46 ` Joern Rennecke
@ 2002-04-12 9:30 ` Andrew Cagney
2002-04-12 9:45 ` Andrew Cagney
1 sibling, 0 replies; 21+ messages in thread
From: Andrew Cagney @ 2002-04-12 9:30 UTC (permalink / raw)
To: joern.rennecke; +Cc: Ben Elliston, gdb-patches
> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: SH5 simulator contribution
2002-04-12 2:46 ` Joern Rennecke
2002-04-12 9:30 ` Andrew Cagney
@ 2002-04-12 9:45 ` Andrew Cagney
2002-04-15 1:48 ` Joern Rennecke
1 sibling, 1 reply; 21+ messages in thread
From: Andrew Cagney @ 2002-04-12 9:45 UTC (permalink / raw)
To: joern.rennecke; +Cc: Ben Elliston, gdb-patches
> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: SH5 simulator contribution
2002-04-12 9:45 ` Andrew Cagney
@ 2002-04-15 1:48 ` Joern Rennecke
2002-04-18 18:32 ` Andrew Cagney
0 siblings, 1 reply; 21+ messages in thread
From: Joern Rennecke @ 2002-04-15 1:48 UTC (permalink / raw)
To: ac131313; +Cc: bje, gdb-patches
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: SH5 simulator contribution
2002-04-15 1:48 ` Joern Rennecke
@ 2002-04-18 18:32 ` Andrew Cagney
2002-04-29 10:23 ` Joern Rennecke
0 siblings, 1 reply; 21+ messages in thread
From: Andrew Cagney @ 2002-04-18 18:32 UTC (permalink / raw)
To: joern.rennecke; +Cc: bje, gdb-patches
> 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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: SH5 simulator contribution
2002-04-18 18:32 ` Andrew Cagney
@ 2002-04-29 10:23 ` Joern Rennecke
2002-04-29 10:47 ` Andrew Cagney
0 siblings, 1 reply; 21+ messages in thread
From: Joern Rennecke @ 2002-04-29 10:23 UTC (permalink / raw)
To: ac131313; +Cc: bje, gdb-patches
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: SH5 simulator contribution
2002-04-29 10:23 ` Joern Rennecke
@ 2002-04-29 10:47 ` Andrew Cagney
2002-04-29 11:30 ` Joern Rennecke
0 siblings, 1 reply; 21+ messages in thread
From: Andrew Cagney @ 2002-04-29 10:47 UTC (permalink / raw)
To: joern.rennecke; +Cc: bje, gdb-patches
>> >> 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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: SH5 simulator contribution
2002-04-29 10:47 ` Andrew Cagney
@ 2002-04-29 11:30 ` Joern Rennecke
0 siblings, 0 replies; 21+ messages in thread
From: Joern Rennecke @ 2002-04-29 11:30 UTC (permalink / raw)
To: ac131313; +Cc: bje, gdb-patches
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
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: SH5 simulator contribution
2002-02-05 17:36 ` Andrew Cagney
2002-04-12 2:46 ` Joern Rennecke
@ 2002-04-12 2:48 ` Joern Rennecke
2002-04-12 2:57 ` Joern Rennecke
` (3 subsequent siblings)
5 siblings, 0 replies; 21+ messages in thread
From: Joern Rennecke @ 2002-04-12 2:48 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Ben Elliston, gdb-patches
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: SH5 simulator contribution
2002-02-05 17:36 ` Andrew Cagney
2002-04-12 2:46 ` Joern Rennecke
2002-04-12 2:48 ` Joern Rennecke
@ 2002-04-12 2:57 ` Joern Rennecke
2002-04-12 2:57 ` Joern Rennecke
` (2 subsequent siblings)
5 siblings, 0 replies; 21+ messages in thread
From: Joern Rennecke @ 2002-04-12 2:57 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Ben Elliston, gdb-patches
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: SH5 simulator contribution
2002-02-05 17:36 ` Andrew Cagney
` (2 preceding siblings ...)
2002-04-12 2:57 ` Joern Rennecke
@ 2002-04-12 2:57 ` Joern Rennecke
2002-04-12 2:57 ` Joern Rennecke
2002-04-12 2:58 ` Joern Rennecke
5 siblings, 0 replies; 21+ messages in thread
From: Joern Rennecke @ 2002-04-12 2:57 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Ben Elliston, gdb-patches
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: SH5 simulator contribution
2002-02-05 17:36 ` Andrew Cagney
` (3 preceding siblings ...)
2002-04-12 2:57 ` Joern Rennecke
@ 2002-04-12 2:57 ` Joern Rennecke
2002-04-12 2:58 ` Joern Rennecke
5 siblings, 0 replies; 21+ messages in thread
From: Joern Rennecke @ 2002-04-12 2:57 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Ben Elliston, gdb-patches
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
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: SH5 simulator contribution
2002-02-05 17:36 ` Andrew Cagney
` (4 preceding siblings ...)
2002-04-12 2:57 ` Joern Rennecke
@ 2002-04-12 2:58 ` Joern Rennecke
5 siblings, 0 replies; 21+ messages in thread
From: Joern Rennecke @ 2002-04-12 2:58 UTC (permalink / raw)
To: Andrew Cagney; +Cc: Ben Elliston, gdb-patches
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
^ permalink raw reply [flat|nested] 21+ messages in thread