From owner-freebsd-toolchain@freebsd.org Tue Aug 2 04:19:57 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 81606BACD07 for ; Tue, 2 Aug 2016 04:19:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 4AFF61E97 for ; Tue, 2 Aug 2016 04:19:57 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x236.google.com with SMTP id f6so189943754ith.0 for ; Mon, 01 Aug 2016 21:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=dtwFuMtSwHU5zelmwSx76VP7a5uCwcD4Q9BaI8BeqrA=; b=jQ7jOuh0rGMU8/FukRAAWnVJ0jSsEOTL4nLkVd/KxMDsiwCzG9MFKDKII2emNA2ax+ sJlHKXW3Du/VUAvuJinv+0WnsCH++QZKVddaras63l3lbV7X6B+UK7K5OCQvIlWjnZLm ZnaFYPxqaWbX3cwk7aZnGC1xsG5Afls4pPwpaDh4bm45swJi70l3tqAhIlrPhUilZQcK HSStuxDuyYF/aTHrnzV+vjuV+76DbS4IRWG47MjOiFVJseXuSEGrKZFw9sEzmcITCA/I CyIxJbBKpNIsXnPXpfBO/QiWHS/aKg/EXCpqX7bwPLc+aLdfbMLK0ih9/Y7dVQepY64u OBKQ== 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; bh=dtwFuMtSwHU5zelmwSx76VP7a5uCwcD4Q9BaI8BeqrA=; b=ekevSK3yIyqLWhhKW0T7I8g0G5Oa60O6QEdK2L9bK52JWXOPJRocYay+H7L631L9V7 iGECHln/ufincRxhpZfX27O7GrXlNmXqhpPUwGgJ500O/v0P0A6xsW8FZkFuPFXLVzAw xn42hXNf3I6+2bJTj4Sen21PaeJ/6DiCGjjU56J+rHintDO5+Tyf6aW7w4T6V3vpRT26 6YCCkvOFJpwLvqtmg8nbBybD5LOv8PlN8o02/xbz6a7b0souSzrWuVAVh10bV6kUP7B2 yyye6P4fBqwDrv6cQtdLnubep+Vn7xDRIAgGKQufPZWvWAKCoAbMbU5kmSlKMf8b/TOo LsTQ== X-Gm-Message-State: AEkoousK6fficWhOtHsReZW0uwU/jc3i6xRmZaClmEuv9I7IfOjAr/HD6a80o1BgXInWISQvx+AzJVlE1bRPlw== X-Received: by 10.36.86.134 with SMTP id o128mr64743142itb.5.1470111596493; Mon, 01 Aug 2016 21:19:56 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.138.28 with HTTP; Mon, 1 Aug 2016 21:19:36 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Tue, 2 Aug 2016 04:19:36 +0000 X-Google-Sender-Auth: Bkp3feH-NQR-KWCcJ2aveymgnIQ Message-ID: Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system To: "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: Tue, 02 Aug 2016 04:19:57 -0000 For some reason Warner's email didn't make it to me, but I spotted it in the list archive. Warner writes: > 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. I'm not sure objcopy (alone) can do what we need, because -N also turns off page alignment for .data. But either way I don't think will be hard to work around. >> 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. Yeah, I planned to bundle it with some knob that already controls lld's dependencies. >> 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. Sounds good. We want to have it done by that point in the list but you're absolutely right that we don't need to wait to start working on it. If it hasn't happened by the time we finish up the earlier tasks I'll look at it then. >> 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 :) Indeed, and that's a big part of my motivation for trying to make lld more readily available as early as possible, even if we're still waiting on some required features. >> 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? Right. > 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 intentionally trying to keep lld decoupled from GCC 4.2 removal, and don't think it should directly enable (or prevent) any progress there. I don't yet have a good handle on GCC 4.2 removal timelines but will definitely pay attention to progress there and potential interaction with lld work. > What's the timeline for all this stuff, do you think? Significant progress is being made in lld at the moment. I don't want to speak for others who are doing much of the work upstream, but I would not be surprised if within two months we can build a working world and kernel with lld (modulo rescue and boot loader fixes). If testing and ports exp-runs go well I'd guess we could make it the default in head a couple of months after that. > 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 :) Yes, fully agree. I want to have lld available as soon as is feasible, but have no intention of trying to remove old GNU ld or GCC 4.2 until a viable path forward exists for all architectures.