This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: SH5 simulator contribution
- From: Joern Rennecke <joern dot rennecke at st dot com>
- To: ac131313 at cygnus dot com
- Cc: bje at redhat dot com, gdb-patches at sources dot redhat dot com
- Date: Mon, 29 Apr 2002 19:29:24 +0100
- Subject: Re: SH5 simulator contribution
- Organization: SuperH UK Ltd.
- 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> <3CCD874A.8010801@cygnus.com>
- Reply-to: joern dot rennecke at st dot com
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