Re: SH5 simulator contribution

[Andrew Cagney <ac131313@cygnus.com>]

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