Re: June 2017 update on using LLVM's lld linker in the FreeBSD base system
On 12 June 2017 at 17:21, Ed Maste wrote: > Another update on using LLD as the FreeBSD base system linker: Since "amd64" and "arm64" look similar, let me clarify one point: arm64 -- 64-bit ARM -- is built with, and has as /usr/bin/ld, LLD 4.0.0. This is true in HEAD and in stable/11 (and hence the upcoming 11.1) amd64 -- 64-bit x86 -- is built with, and has as /usr/bin/ld, GNU BFD ld 2.17.50. LLD is installed as ld.lld; adding -fuse-ld=lld to CFLAGS can be used to test linking various software with LLD. Also, the amd64 linker will not change in stable/11. > Then the ports infrastructure > can automatically use ld.bfd, until the issue is addressed in the > individual port or in LLD. It will be something like > "USES=linker:not_lld" or "LLD_UNSAFE=yes" or so. Still waiting on this; once it is ready I expect to switch amd64 to LLD. > Outstanding issues with i386 and 32-bit arm prevent us from turning it > on for those architectures right now. The LLVM tracking bug in > http://llvm.org/pr23214 depends on those individual issues; i386 > should be relatively straightforward, while arm needs more work. i386 still needs investigation, but progress has been made on 32-bit arm. andrew@ booted an lld-linked arm kernel/userland to the login prompt, with a few workarounds. Note that this is specifically for armv7. LLD does not currently support earlier ARM architectures. TARGET_ARCH=armv7 support is in discussion/planning, and for now I assume that we'd initially switch only it to LLD. TARGET_ARCH=arm and TARGET_ARCH=armv6 will continue to use ld.bfd. It appears we are on a credible path to enable LLD by default in 12.0 for the tier-1 and almost tier-1 architectures of i386, amd64, armv7, arm64. ___ 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"
June 2017 update on using LLVM's lld linker in the FreeBSD base system
Another update on using LLD as the FreeBSD base system linker: > We now have LLD 4.0.0 in the tree and it can build all of > FreeBSD/amd64 kernel and world, and most of ports. LLD 4.0.0 is in HEAD and stable/11, and WITH_LLD_IS_LD and WITH_LLD_BOOTSTRAP are enabled by default for arm64 on both branches. There are a few post-4.0.0 bugfixes in LLD that we need to import into HEAD in short order and MFC for the 11.1 release. It is possible to build both the amd64 and arm64 world + kernel with WITH_LLD_IS_LLD and WITH_LLD_BOOTSTRAP. My daily driver desktop and laptop are using LLD as /usr/bin/ld. >> 6. Request ports exp-runs and issue a call for testing with 3rd party >> software. Fix issues found during this process. > > This is in progress now, in PR 214864. There are currently 270 failing > ports and 963 skipped. The top ten failing ports (by # skipped) are > responsible for 808 of the skipped; addressing those should allow us > to build nearly 98% of the ports collection with LLD. bapt@ and I discussed this at BSDCan and we intend to create a way to flag ports that don't build with LLD. Then the ports infrastructure can automatically use ld.bfd, until the issue is addressed in the individual port or in LLD. It will be something like "USES=linker:not_lld" or "LLD_UNSAFE=yes" or so. >> 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. > > While there is still no timeline set for this, it is already done for > arm64 (where we have no in-tree GNU ld available), and it is close to > being feasible for amd64. Further investigation is needed on i386 and > 32-bit arm before moving forward here. Once the ports infrastructure is in place I plan to enable LLD as /usr/bin/ld by default on amd64. Outstanding issues with i386 and 32-bit arm prevent us from turning it on for those architectures right now. The LLVM tracking bug in http://llvm.org/pr23214 depends on those individual issues; i386 should be relatively straightforward, while arm needs more work. ___ 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"
Re: April 2017 update on using LLVM's lld linker in the FreeBSD base system
On 5 April 2017 at 16:09, Dimitry Andric wrote: > > Note that as of r316432, all of the above is also available in the > stable/11 branch. However some of the changes to FreeBSD haven't yet been merged to stable/11, and it's probably not possible to build world + kernel with LLD (via WITH_LLD_IS_LD) on stable/11 today. I expect these to be merged over time, but this is still very much an experimental feature right now. ___ 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"
Re: April 2017 update on using LLVM's lld linker in the FreeBSD base system
On 5 Apr 2017, at 16:59, Ed Maste wrote: > > Here's a fresh update on LLVM's LLD linker in the base system, > referencing the plan originally posted at the beginning of 2016. This > work is primarily taking place on amd64 right now, and unless > otherwise noted these results apply to amd64. > > First, the completed items: > >> 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on. >> 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld >> on the same architectures that use Clang (amd64, arm, arm64, i386). >> 3. Update lld again (most likely to a snapshot from upstream SVN) once >> it is able to link an unmodified FreeBSD kernel. > > We now have LLD 4.0.0 in the tree and it can build all of > FreeBSD/amd64 kernel and world, and most of ports. > >> 4. Modify the boot loader and kernel builds to avoid using features >> not implemented by lld. >> 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld >> hardlink instead of /usr/bin/ld.bfd. > > This became WITH_LLD_IS_LD for consistency with WITH_CLANG_IS_CC. It > also controls the bootstrap linker: adding WITH_LLD_IS_LD=yes to > src.conf means that the system will be built with LLD, and LLD will be > /usr/bin/ld in the resulting world. > > This option is currently enabled by default on arm64 (only). Note that as of r316432, all of the above is also available in the stable/11 branch. -Dimitry signature.asc Description: Message signed with OpenPGP
April 2017 update on using LLVM's lld linker in the FreeBSD base system
Here's a fresh update on LLVM's LLD linker in the base system, referencing the plan originally posted at the beginning of 2016. This work is primarily taking place on amd64 right now, and unless otherwise noted these results apply to amd64. First, the completed items: > 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on. > 2. Add the bmake build infrastructure, installing as /usr/bin/ld.lld > on the same architectures that use Clang (amd64, arm, arm64, i386). > 3. Update lld again (most likely to a snapshot from upstream SVN) once > it is able to link an unmodified FreeBSD kernel. We now have LLD 4.0.0 in the tree and it can build all of FreeBSD/amd64 kernel and world, and most of ports. > 4. Modify the boot loader and kernel builds to avoid using features > not implemented by lld. > 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld > hardlink instead of /usr/bin/ld.bfd. This became WITH_LLD_IS_LD for consistency with WITH_CLANG_IS_CC. It also controls the bootstrap linker: adding WITH_LLD_IS_LD=yes to src.conf means that the system will be built with LLD, and LLD will be /usr/bin/ld in the resulting world. This option is currently enabled by default on arm64 (only). Next, where we are today: > 6. Request ports exp-runs and issue a call for testing with 3rd party > software. Fix issues found during this process. This is in progress now, in PR 214864. There are currently 270 failing ports and 963 skipped. The top ten failing ports (by # skipped) are responsible for 808 of the skipped; addressing those should allow us to build nearly 98% of the ports collection with LLD. For reference, the top ten ports by # skipped are: audio/openal-soft devel/libunwind editors/libreoffice lang/fpc print/gl2ps editors/emacs lang/gcc6-aux lang/mono archivers/arj multimedia/libxine Finally, future tasks: > 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. While there is still no timeline set for this, it is already done for arm64 (where we have no in-tree GNU ld available), and it is close to being feasible for amd64. Further investigation is needed on i386 and 32-bit arm before moving forward here. ___ 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"
Update on using LLVM's lld linker in the FreeBSD base system
LLD developers have made much progress since my last update in August. Two options used by the FreeBSD build, -dc and -r, are now implemented. The issues with linker script expression support and symbol version maps have been addressed. At this point an LLD built from subversion can link a working FreeBSD-HEAD kernel and world except for the boot loaders. Here's an update on the plan I posted previously: > 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on. > 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. Now complete, with Dimitry's import of Clang 3.9.0 in r309124. There is a WITH_/WITHOUT_LLD knob, which defaults to on for amd64 and arm64, and off for all other architectures for now. > 3. Update lld again (most likely to a snapshot from upstream SVN) once > it is able to link an unmodified FreeBSD kernel. This is now possible, but I'm going to wait for 3.9.0 to settle and for the 3.9.1 update to happen first. > 4. Modify the boot loader and kernel builds to avoid using features > not implemented by lld. There are a few outstanding issues in LLD that prevent linking the boot loaders, but I'm hopeful that they will be addressed in the near future. > 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld > hardlink instead of /usr/bin/ld.bfd. I've added this already, to allow for testing and experimentation, and to provide some linker on arm64 image builds that can be used to bootstrap a later GNU ld or LLVM lld. It defaults to on for arm64 and off everywhere else. Note that the knob affects the installed linker (/usr/bin/ld), but does not change the linker actually used to build world and kernel, which remains GNU ld. > 6. Request ports exp-runs and issue a call for testing with 3rd party > software. Fix issues found during this process. This can start happening any time now for LLD 3.9.0, either by setting WITH_LLD_AS_LD with poudriere, or by using -fuse-ld=lld in LDFLAGS. For example, % cd /usr/src/bin/ls % LDFLAGS=-fuse-ld=lld make > 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. It's still too early to plan a switch by default. ___ 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"
Re: Update on using LLVM's lld linker in the FreeBSD base system
On 1 August 2016 at 17:40, Ed Maste wrote: > Over the past year or so I have been investigating the state of LLVM's > lld linker for use in the FreeBSD base system, to see if it could be > used as FreeBSD's system linker. A quick update: most of the required changes have now made it into LLD, and I'm currently testing with an unmodified upstream LLD. I can now build world and kernel with an out-of-tree LLD (setting XLD=...), when using these src.conf knobs: WITHOUT_BINUTILS WITHOUT_BINUTILS_BOOTSTRAP WITHOUT_BOOT WITHOUT_RESCUE There's some upstream work in progress that may address the the boot issue, or at least part of it. Rescue will still be left for later. LLD 3.9 will be available once dim@'s clang390-import branch is merged to FreeBSD HEAD. Although it's a bit older than the LLD HEAD snapshot I've been using for my testing, it will facilitate further testing and experimentation with LLD (e.g. testing ports builds). ___ 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"
Re: Update on using LLVM's lld linker in the FreeBSD base system
On 1 August 2016 at 17:40, Ed Maste wrote: > Over the past year or so I have been investigating the state of LLVM's > lld linker for use in the FreeBSD base system, to see if it could be > used as FreeBSD's system linker. > > ... > There are a few features used by the FreeBSD base system that lld > developers (intentionally) do not expect to implement, unless they're > reasonably widely used in a variety of different software. If they're > not implemented we can modify FreeBSD to avoid using them. I'm aware > of: > > -N/--omagic, used by some boot loader components. We can achieve the > same effect with a linker script. Warner addressed this for x86 boot components in r305353. We still have an issue: lld does not support -Ttext, but does have an -image-base option to set the start address. It would be nice to reconcile this and LLVM PR 30269 is open to track this for lld. > -dc, used by the rescue build. As long as object files are built > specifically for rescue we can probably use -fno-common instead. I briefly tried to get the rescue build working with lld, but was not successful and have just left it disabled in my tests. We can investigate this later. > -b binary to convert binary files into ELF objects, used by some > device drivers in kernel and module builds. We can use > objcopy(elfcopy) instead. There is now an lld change in progress to add support for -b binary: https://reviews.llvm.org/D24060 ___ 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"
Re: Update on using LLVM's lld linker in the FreeBSD base system
On 2 Aug 2016, at 05:19, Ed Maste wrote:
>
>>> 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.
I believe that all of the base system clang’s for supported branches support
-fuse-ld=lld (perhaps 10.0 didn’t?), so if we have an lld candidate in ports
then it should be easy for user to test it by doing a pkg ins lld and setting
LDFLAGS. Failing that, the fallback to just replacing /usr/bin/ld with a
symlink to /usr/local/bin/ld.lld would probably work for ports testing.
We’re probably going to want a ‘needs bfd / gold instead of lld’ knob for a
while. We might need to patch the gcc versions in ports to accept
-fuse-ld=lld[1].
I suspect the longer tail for LTO. There is a bunch of low-hanging fruit in
the FreeBSD tree where LTO would likely be a win (I’d expect most of the
statically linked stuff to get smaller, if nothing else).
David
[1] gcc and clang interpret -fuse-ld differently. In clang, -fuse-ld={foo}
means ‘${PATH}/ld.{foo}’ is the linker and you should error out if it doesn’t
exist. gcc instead hard codes bfd and gold as the two valid options and rejects
anything else.
smime.p7s
Description: S/MIME cryptographic signature
Re: Update on using LLVM's lld linker in the FreeBSD base system
>> 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. Agreed. We don't have to have a plan for removal before moving forward on lld. 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"
Re: Update on using LLVM's lld linker in the FreeBSD base system
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. ___ 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"
Re: Update on using LLVM's lld linker in the FreeBSD base system
Warner Losh imp at bsdimp.com wrote on Aug 1 22:27:19 UTC 2016 : > On Mon, Aug 1, 2016 at 3:40 PM, Ed Maste wrote: > > > 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). This note is about the status for TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64. clang 3.8.0 is not ready for TARGET_ARCH=powerpc or TARGET_ARCH=powerpc64 yet. (I do not know about clang/clang++ 3.9 or later.) So this is another external tool chain family (so far). clang/clang++ for TARET_ARCH=powerpc does not even generate code for the FreeBSD specified ABI's stack handling properties: It requires a so-called red-zone for signal handling because of when the stack pointer is adjusted for both directions. clang also does not handle some of the assembler notation that is used in the kernel. Neither TARGET_ARCH variant handles C++ exceptions correctly for things built via clang++ 3.8.0. TARGET_ARCH=powerpc64 is missing soft-float support, blocking building libstand as I remember. There is more wrong. See https://llvm.org/bugs/show_bug.cgi?id=25780 : [META] Using Clang as the FreeBSD/ppc system compiler And its "Depends on" list. There are about 6 reports pending. Additional clang related notes: TARGET_ARCH=powerpc notes: with a kernel modified to have signal handling provide a red-zone I've been able to use clang for buildworld and run a system that is a mix of a gcc 4.2.1 based kernel and a clang 3.8.0 based world. But I have to avoid using things that would use C++ exception handling if built via the system clang++ 3.8.0. TARGET_ARCH=powerpc64 note: I've never got that far with clang 3.8.0. xtoolchain related notes: There is no external toolchain in place for TARGET_ARCH=powerpc that I know of. I do build TARGET_ARCH=powerpc64 via devel/powerpc64-gcc and devel/powerpc64-xtoolchain-gcc . But I've never gotten lib32 to work when built from that toolchain so I normally do not build lib32: crtbeginS code problem(s) from not matching the register usage. Where my mostly TARGET_ARCH=powerpc and TARGET_ARCH=powerpc64 source changes are: # svnlite status /usr/src/ M /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp M /usr/src/lib/csu/powerpc64/Makefile ? /usr/src/sys/amd64/conf/GENERIC-NODBG ? /usr/src/sys/amd64/include/include ? /usr/src/sys/arm/conf/RPI2-NODBG ? /usr/src/sys/arm/include/include M /usr/src/sys/boot/ofw/Makefile.inc M /usr/src/sys/boot/powerpc/Makefile.inc M /usr/src/sys/boot/powerpc/kboot/Makefile M /usr/src/sys/boot/uboot/Makefile.inc M /usr/src/sys/conf/Makefile.powerpc M /usr/src/sys/conf/kern.mk M /usr/src/sys/conf/kmod.mk ? /usr/src/sys/powerpc/conf/GENERIC64-NODBG ? /usr/src/sys/powerpc/conf/GENERIC64vtsc ? /usr/src/sys/powerpc/conf/GENERIC64vtsc-NODEBUG ? /usr/src/sys/powerpc/conf/GENERICvtsc ? /usr/src/sys/powerpc/conf/GENERICvtsc-NODEBUG ? /usr/src/sys/powerpc/include/include M /usr/src/sys/powerpc/ofw/ofw_machdep.c M /usr/src/sys/powerpc/powerpc/exec_machdep.c ? /usr/src/sys/x86/include/include (Something along the way made the include/include's, with the nested one pointing to its parent one. I did not explicitly do this.) Some of the .c source changes are tied to my making PowerMac G5's boot reliably when they have lots of RAM. (Just experimentally derived and observed on the G5 examples that I sometimes have access to.) I build with both vt and sc enabled and PS3 disabled. === Mark Millard markmi at dsl-only.net ___ 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"
Re: Update on using LLVM's lld linker in the FreeBSD base system
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 ___ 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"
Update on using LLVM's lld linker in the FreeBSD base system
Over the past year or so I have been investigating the state of LLVM's lld linker for use in the FreeBSD base system, to see if it could be used as FreeBSD's system linker. Why do we need a new linker? Compared to the GNU ld 2.17.50 that we have in the FreeBSD base system, lld will bring: * AArch64 (arm64) support * Link Time Optimization (LTO) * New ABI support * Other linker optimization * Much faster link times * Maintained code base I've posted a couple of status updates on the LLVM mailing list: http://lists.llvm.org/pipermail/llvm-dev/2015-November/092572.html http://lists.llvm.org/pipermail/llvm-dev/2016-March/096449.html Since the last update in March several lld developers have implemented much of the missing functionality. The main blockers were symbol version support and expression evaluation in the linker script expression parser. Both are now nearly complete. There are a few features used by the FreeBSD base system that lld developers (intentionally) do not expect to implement, unless they're reasonably widely used in a variety of different software. If they're not implemented we can modify FreeBSD to avoid using them. I'm aware of: -N/--omagic, used by some boot loader components. We can achieve the same effect with a linker script. -dc, used by the rescue build. As long as object files are built specifically for rescue we can probably use -fno-common instead. -r binary to convert binary files into ELF objects, used by some device drivers in kernel and module builds. We can use objcopy(elfcopy) instead. Davide Italiano and Rafael Ávila de Espíndola presented an update on the state of lld at BSDCan 2016: https://www.bsdcan.org/2016/schedule/events/656.en.html At this point I'm confident that lld is going to be a viable linker for the FreeBSD base system, and am beginning to plan its import. I expect the process will look something like this: 1. Update lld along with the Clang/LLVM 3.9 update that dim@ is working on. 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. 3. Update lld again (most likely to a snapshot from upstream SVN) once it is able to link an unmodified FreeBSD kernel. 4. Modify the boot loader and kernel builds to avoid using features not implemented by lld. 5. Introduce a WITH_LLD_AS_LD knob to have /usr/bin/ld be a ld.lld hardlink instead of /usr/bin/ld.bfd. 6. Request ports exp-runs and issue a call for testing with 3rd party software. Fix issues found during this process. 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. 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. I'm interested in your comments, questions and concerns about this plan. ___ 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"
