From owner-svn-src-head@freebsd.org Fri Apr 7 20:38:17 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C23CAD33E49 for ; Fri, 7 Apr 2017 20:38:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9072BA93 for ; Fri, 7 Apr 2017 20:38:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id a140so589796ita.0 for ; Fri, 07 Apr 2017 13:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=1ylp5hhr5fGL89Tu8ksI7mSAIM86ruYUGjr7e+BtOrI=; b=FX6uRP6SaeVwr61tx9WXC1S6Ub7UBCmVddIoMS2RhVRtGyOE5WlS0SWjITrX86wRu6 3GVs9y7g3CllFySEFyRdE8NZklDRvICIygUWYHqu9GxDGnHj5wUfy67+EeSFb98hcpKd SJJZKzTnfI3yzsJ8GikrcnOlhhg2BUhPIYbWdr/XJgv7vO6p23rt/y/ZG6So+ncKI9an u9iZfP0U3QTU5LizBPYMidSiD6V1shru8QNNnDzOGy5Dwpovrw8VA8lSJl/8HcAFnWpW v62XakCITtCT5xa0c/TtBOAowoFpojAyy4ntTIa8JAkBGEv6Iun2Jg7heQJFiVI6ZJuF nmNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1ylp5hhr5fGL89Tu8ksI7mSAIM86ruYUGjr7e+BtOrI=; b=KLNJQ0XVZ9zlX+mOkAsGprqNSr9Zgcb9EXHNrGq6aIAJkBKMtIQbCsZkQoTTTiUhWB iPEm+9V94wlNPjkNaFXt0IEvD5HjCrSdHt3+Untg78ls++Pl3RNdAI7IaTHknt/ELT9y cS/o8d5JH1UpJLsndcHlmIiCaBvTRJGYSHZ9aL7RM+NGY/30tBQubpq5v9durXL0EoPf WnL3xrX82OeQ2bvudTY20Xcz0KL4LWVwSyTbA8OXGk0hZDvNjs+af6aPnfQbXnlimu8J itXN8cy2vNTsyLTbtrxelTsW140FHESNCDBIQz6TU6zFj5+ukURxrEA9qQqYb7rgO3rP LUVQ== X-Gm-Message-State: AN3rC/49vL+sKbI4I9hJDDqznqFOgjuN6xbW/YWtwnB54bTZ3e3fR3DbD7c0pGet2aR1J4/BWERIc+eDfLTS9w== X-Received: by 10.36.43.77 with SMTP id h74mr1029348ita.60.1491597496761; Fri, 07 Apr 2017 13:38:16 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.146.24 with HTTP; Fri, 7 Apr 2017 13:38:16 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1840:6d1b:29a2:136f] In-Reply-To: <3876116.W5eNvcJ1Jh@ralph.baldwin.cx> References: <201704072002.v37K21Ux032932@repo.freebsd.org> <3876116.W5eNvcJ1Jh@ralph.baldwin.cx> From: Warner Losh Date: Fri, 7 Apr 2017 14:38:16 -0600 X-Google-Sender-Auth: u-TzyNQHXuyh1k0J7DBpf9TZqq0 Message-ID: Subject: Re: svn commit: r316622 - head/share/mk To: John Baldwin Cc: src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 20:38:17 -0000 On Fri, Apr 7, 2017 at 2:10 PM, John Baldwin 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