o) Add TARGET_ABI to the MIPS toolchain build process. This sets the default
ABI to one of o32, n32 or n64. If it is not set, o32 is assumed as that is
the current default.
o) Set the default GCC cpu type to any specified TARGET_CPUTYPE. This is
necessary to have a working "cc" if e.g. mips64 is specified, as binutils
will refuse to link objects using different ISAs in some cases.
o) Add support for n32 and n64 ABIs to binutils and GCC.
o) Add additional required libgcc2 stubs for n32 and n64.
o) Add support for the "mips64r2" architecture to GCC. Add the "octeon"
o) When static linking, wrap default libraries in --start-group and
--end-group. This is required for static linking to work on n64 with the
interdependencies between libraries there. This is what other OSes that
support n64 seem to do, as well.
o) Fix our GCC spec to define __mips64 for 64-bit targets, not __mips64__, the
former being what libgcc, etc., check and the latter seemingly being a
misspelling of a hand merge from a Linux spec.
o) When no TARGET_CPUTYPE is specified at build time, make GCC take the default
ISA from the ABI. Our old defaults were too liberal and assumed that 64-bit
ABIs should default to the MIPS64 ISA and that 32-bit ABIs should default to
the MIPS32 ISA, when we are supporting or will support some systems based on
earlier 32-bit and 64-bit ISAs, most notably MIPS-III.
o) Merge a new opcode file (and support code) from a later version of binutils
and add flags and code necessary to support Octeon-specific instructions.
This should also make merging opcodes for other modern architectures easier.
Reviewed by: imp
Unlike the unisex architecutres we've had so far, mips is bisexual.
These tools can produce either byte sex, and the compiler/make
determines the proper gender to use. Otherwise, we'd have to have had
mipsel and mipseb in all the places that we have just mips. And there
are other complications with doing that (binutils doesn't like to
build mips tools without both byte genders, it seems).
Introduced BINUTIL_ARCH so that other bisexual architectures can a
generic mechanism.
We cannot just define MACHINE_ARCH as mips because we need to
differentiate big and little endian types of binaries. Discussions on
freebsd-arch have hashed out this issue (and the parallel libc
issues). NetBSD is moving towards mipsel and mipseb for their two
flavors of mips ports (in time for 1.4, if this change hasn't already
been accomplished).
I've been building i386 worlds with this tree for a three months with
these files in place with no ill effects.
