Add little/big endian multilib variants to mips*-rtems*
Ralf Corsepius
ralf.corsepius@rtems.org
Sat Jun 10 04:06:00 GMT 2006
On Fri, 2006-06-09 at 14:46 -0500, Joel Sherrill wrote:
> Richard Sandiford wrote:
>
> >Joel Sherrill <joel.sherrill@oarcorp.com> writes:
> >
> >
> >>Does there need to be a special error catcher for mips*el-rtems so it
> >>can't be configured?
> >>
> >>
> >
> >If it has to be mips-rtems (not mipsFOO-rtems), then I suggest
> >just removing the first "*" from "mips*-rtems*".
> >
> >
> >
> We do build a mips64-rtems so that won't work. Close though.
Fixing this would be trivial:
--- config.gcc (revision 114538)
+++ config.gcc (working copy)
@@ -1560,7 +1560,7 @@
tm_defines="MIPS_ISA_DEFAULT=3 MIPS_ABI_DEFAULT=ABI_O64"
use_fixproto=yes
;;
-mips*-*-rtems*)
+mips64-*-rtems | mips-*-rtems*)
tm_file="elfos.h ${tm_file} mips/elf.h mips/rtems.h rtems.h"
tmake_file="mips/t-elf t-rtems mips/t-rtems"
;;
Some fundamental questions, I can't answer, however would remain:
* Is such a mips64-*rtems* target useful at all?
* Has mips64-rtems* (before having added le/be multilib variants) ever
been useful.
* Can "mips64" be implemented as multilib variant of "mips"?
Ralf
More information about the Gcc-patches
mailing list