This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: SH5 simulator contribution
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: joern dot rennecke at st dot com
- Cc: bje at redhat dot com, gdb-patches at sources dot redhat dot com
- Date: Mon, 29 Apr 2002 13:47:54 -0400
- Subject: Re: SH5 simulator contribution
- References: <15451.47633.743434.331956@scooby.brisbane.redhat.com> <3C5F55F3.2030807@cygnus.com> <15455.24394.87381.934711@scooby.brisbane.redhat.com> <3C5F66BB.50001@cygnus.com> <15455.31263.847272.160235@scooby.brisbane.redhat.com> <3C6008DF.5020702@cygnus.com> <15456.16085.191791.112025@scooby.brisbane.redhat.com> <3C6088B3.7080702@cygnus.com> <3CB6AD19.CCDD835A@st.com> <3CB70F11.6010609@cygnus.com> <3CBA940B.B99F0E4C@st.com> <3CBF73A3.2090409@cygnus.com> <3CCD81CD.CBAC3A62@st.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