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: Ben Elliston <bje at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Fri, 12 Apr 2002 12:45:05 -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>
> 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