Date: Fri, 7 Apr 2017 14:38:16 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@freebsd.org> Cc: src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r316622 - head/share/mk Message-ID: <CANCZdfrgmrXS=%2BJEnPbU2tZ4WvU-zrAXN3chw31pAC%2BOf0ibFA@mail.gmail.com> In-Reply-To: <3876116.W5eNvcJ1Jh@ralph.baldwin.cx> References: <201704072002.v37K21Ux032932@repo.freebsd.org> <3876116.W5eNvcJ1Jh@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 7, 2017 at 2:10 PM, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrgmrXS=%2BJEnPbU2tZ4WvU-zrAXN3chw31pAC%2BOf0ibFA>