This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Add little/big endian multilib variants to mips*-rtems*

Ralf Corsepius wrote:

On Fri, 2006-06-09 at 14:46 -0500, Joel Sherrill wrote:

Richard Sandiford wrote:

Joel Sherrill <> 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 @@
+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?

I don't know.

* Has mips64-rtems* (before having added le/be multilib variants) ever
been useful.

Again, I don't particularly know. I don't have a way to test such a target.

* Can "mips64" be implemented as multilib variant of "mips"?

I don't know. Can gcc do this?

If the answer to this is yes, then I don't know that the answer to the other questions
matter. I would rather ship one mips toolset RPM set with a big mulitilib. Will
a mips-rtems binutils and gdb work with a 64-bit multilib?

If we can add 64 bit multilib options later, then it is safe to drop the target now. If it is
being used, someone will complain eventually and we can add the 64 bit multilib variants. :)



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]