From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 22:15:53 2013 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94C28251 for ; Wed, 27 Feb 2013 22:15:53 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id 2FAC3681 for ; Wed, 27 Feb 2013 22:15:52 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.5/8.14.5) with ESMTP id r1RMFqUv020229; Wed, 27 Feb 2013 16:15:52 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.5/8.14.5/Submit) id r1RMFqqW020228; Wed, 27 Feb 2013 16:15:52 -0600 (CST) (envelope-from brooks) Date: Wed, 27 Feb 2013 16:15:52 -0600 From: Brooks Davis To: Warner Losh Subject: Re: [RFC] external compiler support Message-ID: <20130227221552.GC19594@lor.one-eyed-alien.net> References: <20130227003517.GB7348@lor.one-eyed-alien.net> <28404C12-67F3-44F0-AB28-02B749472873@bsdimp.com> <51BB3E17-128A-4989-B272-D8B40D4B854B@bsdimp.com> <20130227190804.GB17489@lor.one-eyed-alien.net> <13FB8CB0-9937-4BD8-AE89-0D24494D8663@bsdimp.com> <20130227214445.GA19594@lor.one-eyed-alien.net> <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2JFBq9zoW8cOFH7v" Content-Disposition: inline In-Reply-To: <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arch@FreeBSD.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 22:15:53 -0000 --2JFBq9zoW8cOFH7v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 27, 2013 at 02:47:59PM -0700, Warner Losh wrote: >=20 > On Feb 27, 2013, at 2:44 PM, Brooks Davis wrote: >=20 > > On Wed, Feb 27, 2013 at 02:01:42PM -0700, Warner Losh wrote: > >>=20 > >> On Feb 27, 2013, at 12:08 PM, Brooks Davis wrote: > >>=20 > >>> On Wed, Feb 27, 2013 at 09:08:05AM -0700, Warner Losh wrote: > >>>> Ooops, forgot to add one item.. > >>>>=20 > >>>>=20 > >>>> On Feb 27, 2013, at 8:57 AM, Warner Losh wrote: > >>>>=20 > >>>>>=20 > >>>>> On Feb 26, 2013, at 5:35 PM, Brooks Davis wrote: > >>>>>=20 > >>>>>> Below (and at http://people.freebsd.org/~brooks/patches/xcc.diff) = you > >>>>>> can find an initial patch with proposed commit for external compil= er > >>>>>> support. It relies on the existing cross binutils as I'm finding = that > >>>>>> the two are fairly separable. With this patch I've been able to b= uild > >>>>>> from amd64 to arm, amd64, and i386 using clang from the lang/clang= -devel > >>>>>> port. I've also compiled the tree with a customized clang being > >>>>>> developed at the University of Cambridge. > >>>>>=20 > >>>>> Cool! > >>>>>=20 > >>>>>> The patch is untested with gcc. > >>>>>=20 > >>>>> I'd like to see it tested with gcc :) > >>>>>=20 > >>>>>> Does this seem like a reasonable approach? I do plan to look at e= xternal > >>>>>> binutils support, but it's not on the critical path for our curren= t work > >>>>>> so I've opted to avoid it for now. > >>>>>=20 > >>>>> The patches I posted a few months ago had that as well... > >>>>>=20 > >>>>>> As a bonus for those who don't need an external compiler, but do r= un > >>>>>> make buildworld frequently, the XCC, XCXX, and XCPP variables can = be set > >>>>>> to the location of the installed base system compiler to avoid bui= lding > >>>>>> the compiler twice during buildworld. > >>>>>=20 > >>>>> I think this will work, but it is kludgy. I had created a __X=3D which was prepended to ${CC}, et al, in sys.mk. It was only def= ined when you set CROSS_COMPILER_PATH (or EXTERNAL_COMPILER_PATH, I forget)= during the cross building stage. It also had the advantage of making exter= nal cross binutils available. Your patch could fairly easily use this inter= face instead of having to set 3 different variables, which will morph to 10= when you add binutil support. > >>>>=20 > >>>=20 > >>> I think something like this will have to be done for binutils given t= he > >>> way -B works, but I don't think it's workable in the general compiler > >>> case because I want to be able to use gcc46 or a future clang33 or > >>> similar as CC without changing the system compiler. Ideally I'd > >>> also like to support clang's method of finding appropriate binutils > >>> by looking first for /binutils/path/${TARGET_TRIPLE}-tool and then > >>> /binutils/path/tool. > >>=20 > >> I didn't know that clang did this, but that's certainly doable. > >=20 > > The key is that for it to work we need to set each tool's name > > individually. > >=20 > >>> As a strawman, let's say we add a CROSS_COMPILER_PATH and a > >>> CROSS_BINUTILS_PATH. The former will set XCC, XCXX, and XCPP if they > >>> are unset. The latter will control -B and set the various binutils > >>> variables (XNM, XLD, etc). > >>=20 > >> I'm not sure I like splitting things like that. It is unnatural. > >=20 > > That's the traditional view with lots of historic merit. At least in > > the short term it's not a useful view for me. I want to be able to > > use our existing infrastructure to build a cross binutils and then use > > it with an external compiler. In a clang world, we currently have one > > compiler and many binutils unless we gratuitously build many compilers > > as the FreeBSD build system currently does. Some day we will likely ha= ve > > an all-llvm toolchain available and then we will have one toolchain for > > all supported architectures. > >=20 > > I suppose could hack what I want to do into the traditional single > > toolchain world view by build a mips64 xdev toolchain and then building > > a linkfarm and/or set of wrapper scripts to it and the clang I want to > > include, but that seems problematic from a reproducability perspective > > (not to mention performance if I need wrappers to set -B). > >=20 > > Having a CROSS_TOOLCHAIN_PATH path that sets both would probably be a > > useful compromise in this regard. >=20 > Are you suggesting something like: >=20 > CROSS_COMPILER_PATH?=3D${CROSS_TOOLCHAIN_PATH} > CROSS_BINUTILS_PATH?=3D${CROSS_TOOLCHAIN_PATH} >=20 > If so, I'd agree, that would be a very useful compromise: hits my ease of= use issues, and lets you do what you need on the theory that others will l= ikely need it too. That's exactly what I'm thinking. I hope a lot of the cruft in Makefile.inc1 goes away as Simon's work is integrated, but for now I figure a little more won't hurt much... -- Brooks --2JFBq9zoW8cOFH7v Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFRLoWXXY6L6fI4GtQRAjETAJ9yGx7u7OUqSMbLudSYWpG56zUPUwCgz5XI quxOKx98nPm1gO6cu+3ODzA= =b67M -----END PGP SIGNATURE----- --2JFBq9zoW8cOFH7v--