From owner-freebsd-toolchain@freebsd.org Mon Aug 1 22:27:19 2016 Return-Path: Delivered-To: freebsd-toolchain@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 D8816BAC3BA for ; Mon, 1 Aug 2016 22:27:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (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 A238B11EC for ; Mon, 1 Aug 2016 22:27:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id f6so257374798ith.1 for ; Mon, 01 Aug 2016 15:27:19 -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=CVxiwHmcCh2hHuNCCX1sLjkLTT5DsUWfr9HstkffC/Y=; b=Lj26jogi0xRuz+YOemXsEKNde2yVEDeZDwTEpQhfOJ6Jk6DIit3VmTQf3C0Prc+zO7 w8HGWvEynciJw4fQDoj4cHV/zuCb4APVITgySc+YOZRRRecRuO994gGnliXh0MLBqFQF Eo9+BI7P8abwOpa953/xEIEhx2kM41C560thC/MNWxAkg+wqWHdi6d5gZJnYPymargsP jy54S1SPJLGf/gO/byGyaZTqWU697/OsbnPV1oO3vBAqZNfhoaNFcyRbpKdjM6r243CY 41JypWWhOiq+x8xJMU0sKf4Ns8dCJQAzKu7xW0Ga+hKBxqn7Kj9yfbKDU3MC0EIr/n4N QdVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CVxiwHmcCh2hHuNCCX1sLjkLTT5DsUWfr9HstkffC/Y=; b=eoqV/TQwojC2LHsh8dx4RGpKUZOrqklYI4mz4S/+p0/7RBMNX6JL/6MW1Kh67//wWk ECEXvVmSRybrZ7WwjyMfe5knW25giawNS1orOXlSSy9lVoe4qQzmVC5v6652V5OS33CL BgUPAgJTB9OunoIRcslRSreD+7b0WoXUWub0TgNEHAJC/HuYPUQiq/IwQtUWG9dVVcGw wabnumZaOkCb6sKMls7qHs7pAkLxmPJwf+3k0o8VFK/8zTZNCxrJiMhpRqZLRS+rEOI3 cUXrSIYUrFxDz0F2mnqAThkq/GqjcgksaHyY4SAHGb/9BHhPlsiuNnqOYK4mBS7Rzkks yZog== X-Gm-Message-State: AEkoouu8d23RAubM5EIKhPFg/byh+hRVHqMWh5TgnbhjKbCEq+G7WUAo7NiQ9pqPj7e/zOWHz/N4rAlpPqb7fQ== X-Received: by 10.36.39.195 with SMTP id g186mr55343822ita.53.1470090438981; Mon, 01 Aug 2016 15:27:18 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Mon, 1 Aug 2016 15:27:18 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: References: From: Warner Losh Date: Mon, 1 Aug 2016 16:27:18 -0600 X-Google-Sender-Auth: sUBsNtZY-EXrvG_5SKoh2j1f2hI Message-ID: Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system To: Ed Maste Cc: "freebsd-toolchain@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 22:27:19 -0000 On Mon, Aug 1, 2016 at 3:40 PM, Ed Maste wrote: > -N/--omagic, used by some boot loader components. We can achieve the > same effect with a linker script. Agreed. Or objcopy even. > 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld > on the same architectures that use Clang (amd64, arm, arm64, i386). I > don't think there's a need for a WITH_LLD src.conf knob, but will add > one if desired. I'm on the fence here. Since it is ld.lld, I'm not sure there's much value here so long as it falls under one of the clang WITH/WITHOUT symbols. > 4. Modify the boot loader and kernel builds to avoid using features > not implemented by lld. This can be done in parallel starting now. I may take a stab at the boot loader bits since I think that will be easy. > 6. Request ports exp-runs and issue a call for testing with 3rd party > software. Fix issues found during this process. Experience suggests this may be the long poll :) > 7. Switch /usr/bin/ld to ld.lld by default in head for the Clang-using > architectures. Add a WITHOUT_LLD_AS_LD knob to switch back to GNU ld. For the WITH/WITHOUT things, this is just a matter of changing the default MK_foo setting, right? > There is (some) support for mips and powerpc in lld, but I'm not sure > how well tested it is. RISC-V is not yet supported but there is a > desire to have a full LLVM-based RISC-V toolchain. I'm not aware of > any plan with respect to sparc64 in lld. In any case, I do not plan to > address these architectures in the initial lld work. In the near term > they will continue to use GNU ld 2.17.50. OK. How does this square up against the gcc 4.2 removal timelines and plans? Once gcc is gone, we'll have to use an external toolchain anyway to build mips at least (though clang is close, it isn't there yet despite Sean Bruno's wonderful work). > I'm interested in your comments, questions and concerns about this plan. What's the timeline for all this stuff, do you think? Generally, I like it though. My concerns are mostly with ports and gcc plans. Though it isn't coupled to gcc, I'd suggest that we want to have a joint plan for both before we get out the axes. Note this is purely a timing argument, not whether to get them out, just when :) Warner