On Mon, Aug 1, 2016 at 3:40 PM, Ed Maste <ema...@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. > 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 _______________________________________________ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
