From owner-freebsd-arch@FreeBSD.ORG Wed Feb 27 21:48:05 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7E81E3DB for ; Wed, 27 Feb 2013 21:48:05 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-gh0-f175.google.com (mail-gh0-f175.google.com [209.85.160.175]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6B9253 for ; Wed, 27 Feb 2013 21:48:04 +0000 (UTC) Received: by mail-gh0-f175.google.com with SMTP id g18so167087ghb.34 for ; Wed, 27 Feb 2013 13:48:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=dM2oANj8yh4iHtFVqoxACVprYNaX+Jwaumg6xQxXueI=; b=iVWRElImv4130R3CQmQnQ+9jhLtCrd1N9l9bu6JH3dTX2ladzdJNdIRhqVtpv9lEb0 LEJq4nJglksAbrThTZfNByuZq06ij2dE3diAlZ5rQzXNUA/QUcdZfBp++ipHBVDcwBp/ vBSvRG1gK/OX+aQONz2dtu6ayVbY+64QoX2djO+bpMu3DXkbv7KOfIYfWr5/sHrbFRe7 xUEo5STq5I09y8H3FLf+C2sOrQBZ0kT7TRUUSuMBWFJwN/ixtYu1K1Csnk1IqPoGMKyl OkUUGnhU1imcK3QH1o33rMDmUVZtF45WiPl6f1nhulGgpu8L53GqyAnkRKv4RorqLVwi 6tdg== X-Received: by 10.236.179.37 with SMTP id g25mr2959289yhm.47.1362001684483; Wed, 27 Feb 2013 13:48:04 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id b62sm9856449yhf.13.2013.02.27.13.48.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 13:48:03 -0800 (PST) Sender: Warner Losh Subject: Re: [RFC] external compiler support Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130227214445.GA19594@lor.one-eyed-alien.net> Date: Wed, 27 Feb 2013 14:47:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1CC1DB5A-E87A-456C-AD2C-E203146BB736@bsdimp.com> 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> To: Brooks Davis X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmQbnLwIja/1Nqq2DNUlyTiDHXi2U0VfQehMdYokiok636f92H2gO72OdxztXZ8YBGHoBT0 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 21:48:05 -0000 On Feb 27, 2013, at 2:44 PM, Brooks Davis wrote: > 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 = compiler >>>>>> 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 = build >>>>>> 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 = external >>>>>> binutils support, but it's not on the critical path for our = current 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 = run >>>>>> make buildworld frequently, the XCC, XCXX, and XCPP variables can = be set >>>>>> to the location of the installed base system compiler to avoid = building >>>>>> 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 defined when you set CROSS_COMPILER_PATH (or = EXTERNAL_COMPILER_PATH, I forget) during the cross building stage. It = also had the advantage of making external cross binutils available. Your = patch could fairly easily use this interface 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 = the >>> 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 = have > 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. Are you suggesting something like: CROSS_COMPILER_PATH?=3D${CROSS_TOOLCHAIN_PATH} CROSS_BINUTILS_PATH?=3D${CROSS_TOOLCHAIN_PATH} 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 likely need it too. Warner=