svn commit: r316622 - head/share/mk

[Warner Losh]

On Fri, Apr 7, 2017 at 2:10 PM, John Baldwin <jhb at freebsd.org> wrote:
> On Friday, April 07, 2017 08:02:01 PM John Baldwin wrote:
>> Author: jhb
>> Date: Fri Apr  7 20:02:01 2017
>> New Revision: 316622
>> URL: https://svnweb.freebsd.org/changeset/base/316622
>>
>> Log:
>>   Explicitly set the desired MIPS ABI in toolchain flags.
>>
>>   Specifically, set '-mabi=XX' in AFLAGS, CFLAGS, and LDFLAGS.  This permits
>>   building MIPS worlds and binaries with a toolchain whose default output
>>   does not match the desired TARGET_ARCH.
>>
>>   _LDFLAGS (which is used with LD instead of with CC) required an update as
>>   LD does not accept the -mabi flags (so they must be stripped from LDFLAGS
>>   when generating _LDFLAGS).  For bare uses of LD (rather than linking via
>>   CC), the desired ABI must be set by setting an explicit linker emulation
>>   as done in r316514 for kernels and kernel modules.
>
> With this (and other recent commits), I can build (and run) mips and mips64
> world + kernels under QEMU with external GCC from ports via the
> mips-xtoolchain-gcc package.  (mipsn32 also builds, but it fails to boot in
> the same failure case for both old and new GCC)
>
> Building mips:
>
> make CROSS_TOOLCHAIN=mips-gcc TARGET_CPUTYPE=mips3 TARGET_ARCH=mips buildworld
>
> For mips64 and mipsn32 TARGET_CPUTYPE is not required and only TARGET_ARCH
> has to be changed.
>
> (Previously mips-gcc has worked for 32-bit mips as that was the default
> target for mips-gcc.  There is a mips64-xtoolchain-gcc that targets mips64
> by default that previously worked for mips64.  However, you can now use
> either of these toolchains to build any mips variant.  Previously mips64-gcc
> could only build mips64, and mips-gcc could only build o32 mips.  Neither
> package was able to build n32.  We could perhaps drop the mips64-gcc package
> at some point in the future.)

Frist, let me thank you for doing all this. It helps make the external
tool-chain more viable, which is nothing but good imho.

Yea, the mips64-gcc is a legacy of always requiring the compiler to
produce the right binaries by default design goal we had from way
back. It's useful for forcing native compilers to always do the right
thing which is extremely helpful for ports and such working right out
of the box.  We had a number of nasty bugs related to this not being
the case when we had this sort of thing in the past, but those got
resolved quickly because of the requirement. It would be nice to have
some way to force going backwards for testing (eg, the compiler must
produce the right binary and we're not going to help it out at all),
but it's not as important as it used to be and is easy enough to hack
if you want to test it (so don't take this as a request for change
unless you're really excited by the idea).

But for cross compilers, it's less helpful because you wind up in
situations like this where it's a hassle to have N different ones
laying around. It's trivial to hack gcc to generate the right arch. It
seemed reasonable when N was 4 maybe 5. However, now there's 10
different ones with the hard float variants, and even at 4 it was
starting to be too much. We were only saved by the fact that we had
mipsel and mips64 as the major two that people cared about, so N was
effectively only 1 or 2 for most use cases. It also makes some sense
if one wanted to try out the new "exoitic" ABIs that have been defined
by MIPS that few people actually use (there's a matrix of 32 or 64 of
them!). All in all, I'm glad to see that we've changed this
requirement, and despite pushing very hard for it years ago think it's
the right change today.

The TARGET_CPUTYPE=mips3 likely should be the default in the build
system. We require mips3 or better ISA for our O32 ABI. Since we
require that, making the user set this always is a friction point that
we should file off. It's not like any other architecture. I'll look at
making that the overridable default if I can find a few minutes
sometime.

I guess that's a long way of saying that 'yes, we can drop mips64-gcc
and friends for the ports/packages'

Warner