Date: Tue, 2 Aug 2016 04:19:36 +0000 From: Ed Maste <emaste@freebsd.org> To: "freebsd-toolchain@freebsd.org" <freebsd-toolchain@freebsd.org> Subject: Re: Update on using LLVM's lld linker in the FreeBSD base system Message-ID: <CAPyFy2AN7iJ1L7gM=qjsBq8_NKTA-t-u-GSk5%2B-pWX%2B_V5ztzQ@mail.gmail.com> In-Reply-To: <CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA@mail.gmail.com> References: <CAPyFy2D-j6djHHiXk9D3dmj5xXjKGgoOEnUK7rHvbc=Hc28dxA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <emaste at freebsd.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2AN7iJ1L7gM=qjsBq8_NKTA-t-u-GSk5%2B-pWX%2B_V5ztzQ>