Hi all, LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production use at least for x86-64 (and probably for AArch64 and MIPS). I believe you've heard a few good news about the linker -- it just works <http://lld.llvm.org/#features> and is very fast <http://lld.llvm.org/#performance>, clean, compact and supported by the active community. I don't think I need to reiterate why having a good linker is important for us as the LLVM community. There's one thing you can help us without writing even a line of code. Please use it! Using LLD to link LLVM/clang/etc is easy. You need to check out the LLD repository just like you probably already did for clang, build it, and then install it. LLD will be installed as ld.lld (and it won't be used by default.) After that, re-run cmake with -DLLVM_ENABLE_LLD=On along with your usual options so that LLD will be used to build LLVM. For the details of the build process, please see http://lld.llvm.org/#build. Thanks, Rui -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170314/e2e9ec51/attachment.html>
Is bugs.llvm.org still the best place to report LLD bugs? Is anyone watching those bug reports? For example I reported https://bugs.llvm.org/show_bug.cgi?id=32254 yesterday but I'm not sure if anyone saw it. Regards, Andrew On Tue, Mar 14, 2017 at 2:39 PM, Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production > use at least for x86-64 (and probably for AArch64 and MIPS). I believe > you've heard a few good news about the linker -- it just works > <http://lld.llvm.org/#features> and is very fast > <http://lld.llvm.org/#performance>, clean, compact and supported by the > active community. I don't think I need to reiterate why having a good > linker is important for us as the LLVM community. > > There's one thing you can help us without writing even a line of code. > Please use it! > > Using LLD to link LLVM/clang/etc is easy. You need to check out the LLD > repository just like you probably already did for clang, build it, and then > install it. LLD will be installed as ld.lld (and it won't be used by > default.) After that, re-run cmake with -DLLVM_ENABLE_LLD=On along with > your usual options so that LLD will be used to build LLVM. > > For the details of the build process, please see > http://lld.llvm.org/#build. > > Thanks, > Rui > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170314/fb61e0fd/attachment.html>
Yes that's the right place to file a bug. However, as to LLD/Mach-O, that isn't being developed actively. On Tue, Mar 14, 2017 at 11:50 AM, Andrew Kelley <superjoe30 at gmail.com> wrote:> Is bugs.llvm.org still the best place to report LLD bugs? Is anyone > watching those bug reports? > > For example I reported https://bugs.llvm.org/show_bug.cgi?id=32254 > yesterday but I'm not sure if anyone saw it. > > Regards, > Andrew > > On Tue, Mar 14, 2017 at 2:39 PM, Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production >> use at least for x86-64 (and probably for AArch64 and MIPS). I believe >> you've heard a few good news about the linker -- it just works >> <http://lld.llvm.org/#features> and is very fast >> <http://lld.llvm.org/#performance>, clean, compact and supported by the >> active community. I don't think I need to reiterate why having a good >> linker is important for us as the LLVM community. >> >> There's one thing you can help us without writing even a line of code. >> Please use it! >> >> Using LLD to link LLVM/clang/etc is easy. You need to check out the LLD >> repository just like you probably already did for clang, build it, and then >> install it. LLD will be installed as ld.lld (and it won't be used by >> default.) After that, re-run cmake with -DLLVM_ENABLE_LLD=On along with >> your usual options so that LLD will be used to build LLVM. >> >> For the details of the build process, please see >> http://lld.llvm.org/#build. >> >> Thanks, >> Rui >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170314/64ffedb7/attachment.html>
> Date: Tue, 14 Mar 2017 11:39:22 -0700 > From: Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> > > Hi all, > > LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production > use at least for x86-64 (and probably for AArch64 and MIPS). I believe > you've heard a few good news about the linker -- it just works > <http://lld.llvm.org/#features> and is very fast > <http://lld.llvm.org/#performance>, clean, compact and supported by the > active community. I don't think I need to reiterate why having a good > linker is important for us as the LLVM community.FWIW, we're using lld as the system linker (and clang as the system compiler) on the upcoming OpenBSD/arm64. The system is self-hosting and we've had to fix only a couple of small things in the way we use the linker to get to this point. All security-related features we rely on (-pie, -static -pie, W^X, .openbsd.randomdata) seem to work just fine. So I'd say AArch64 is defenitely there. A big thank you, Mark
On Tue, Mar 14, 2017 at 12:07 PM, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:> > Date: Tue, 14 Mar 2017 11:39:22 -0700 > > From: Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> > > > > Hi all, > > > > LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production > > use at least for x86-64 (and probably for AArch64 and MIPS). I believe > > you've heard a few good news about the linker -- it just works > > <http://lld.llvm.org/#features> and is very fast > > <http://lld.llvm.org/#performance>, clean, compact and supported by the > > active community. I don't think I need to reiterate why having a good > > linker is important for us as the LLVM community. > > FWIW, we're using lld as the system linker (and clang as the system > compiler) on the upcoming OpenBSD/arm64. The system is self-hosting > and we've had to fix only a couple of small things in the way we use > the linker to get to this point. All security-related features we > rely on (-pie, -static -pie, W^X, .openbsd.randomdata) seem to work > just fine. So I'd say AArch64 is defenitely there. >Out of curiosity, what's the story about architectures other than AArch64? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170314/a281c54d/attachment.html>
On 14 Mar 2017, at 18:39, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production use at least for x86-64 (and probably for AArch64 and MIPS).We’re now using it with all three architectures on FreeBSD (though only the n64 ABI for MIPS) and will file bugs. One QoI issue that’s bitten us a couple of times is that the versions of clang and lld must match for LTO to work. If they don’t, we don’t get an error message, we simply get programs that segfault on startup. I’m a bit surprised that reading the bitcode doesn’t return an error that LLD can report and refuse to link. We’ve seen this error mixing clang 4.0 and lld trunk. That’s going to make enabling LTO for FreeBSD package builds problematic once we start shipping lld in the base system - anything built with the system compiler will work fine, but anything built with a compiler from ports will silently generate non-working binaries. Fortunately for LLVM, this includes building a non-working tablegen, so the build fails rather than appearing to succeed and giving non-working binaries. For dogfooding purposes, it would be very helpful if the LLVM CMake files allowed you to specify the suffix for the system clang and LLD to use in a single place. Currently, telling it to use lld will pass -fuse-ld=lld, but we typically need to actually pass -fuse-ld=lld40 or -fuse-ld=lld-devel to pick the LLD version that matches the compiler version that we’re using. David
On Wed, Mar 15, 2017 at 2:55 AM, David Chisnall via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On 14 Mar 2017, at 18:39, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > > > > LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for > production use at least for x86-64 (and probably for AArch64 and MIPS). > > We’re now using it with all three architectures on FreeBSD (though only > the n64 ABI for MIPS) and will file bugs. One QoI issue that’s bitten us a > couple of times is that the versions of clang and lld must match for LTO to > work. If they don’t, we don’t get an error message, we simply get programs > that segfault on startup. I’m a bit surprised that reading the bitcode > doesn’t return an error that LLD can report and refuse to link. We’ve seen > this error mixing clang 4.0 and lld trunk. >If you can put a --reproduce archive up somewhere and file a bug that would be really useful. The bitcode should be backward compatible. I would not be surprised by older LLD and newer Clang causing issues, but the reverse Should Work. -- Sean Silva> > That’s going to make enabling LTO for FreeBSD package builds problematic > once we start shipping lld in the base system - anything built with the > system compiler will work fine, but anything built with a compiler from > ports will silently generate non-working binaries. Fortunately for LLVM, > this includes building a non-working tablegen, so the build fails rather > than appearing to succeed and giving non-working binaries. > > For dogfooding purposes, it would be very helpful if the LLVM CMake files > allowed you to specify the suffix for the system clang and LLD to use in a > single place. Currently, telling it to use lld will pass -fuse-ld=lld, but > we typically need to actually pass -fuse-ld=lld40 or -fuse-ld=lld-devel to > pick the LLD version that matches the compiler version that we’re using. > > David > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170315/9463b1ed/attachment.html>
Any idea of the quality/completeness of the gdb_index support? I've started using gdb_index recently (reduces GDB startup time for Clang from 50 seconds to 3 seconds - though I haven't measure how much it increases link time*) & it's really handy. Would love to have some assurance it's expected to work for LLD. Simple experiments seem to indicate that it's OK/good. Though a quick llvm-dwarfdump of gdb_index between the two linkers shows about a 10% disparity in size (LLD's is smaller) given the same inputs. (219MB v 196MB of text dumped - I didn't compare the actual section sizes) *though honestly I'd be willing to trade startup time for link time 1:1 even, because builds/links are already long enough that I go off and do something else - whereas getting GDB start down to 3 seconds, I can start writing my breakpoint command, etc, in those 3 seconds and be all but unaffected by it - at 50 seconds I basically have to go off and do something else/context switch/etc. On Tue, Mar 14, 2017 at 11:40 AM Rui Ueyama via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi all, > > LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production > use at least for x86-64 (and probably for AArch64 and MIPS). I believe > you've heard a few good news about the linker -- it just works > <http://lld.llvm.org/#features> and is very fast > <http://lld.llvm.org/#performance>, clean, compact and supported by the > active community. I don't think I need to reiterate why having a good > linker is important for us as the LLVM community. > > There's one thing you can help us without writing even a line of code. > Please use it! > > Using LLD to link LLVM/clang/etc is easy. You need to check out the LLD > repository just like you probably already did for clang, build it, and then > install it. LLD will be installed as ld.lld (and it won't be used by > default.) After that, re-run cmake with -DLLVM_ENABLE_LLD=On along with > your usual options so that LLD will be used to build LLVM. > > For the details of the build process, please see > http://lld.llvm.org/#build. > > Thanks, > Rui > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170316/9d4c8c00/attachment.html>
I personally haven't tried gdb_index, and I don't know the quality of the produced index. Most of the code was written by George. One thing I noticed about the feature (and filed as http://bugs.llvm.org/show_bug.cgi?id=32228) is that our gdb_index feature is much slower than the gold. Apparently there's room for improvement. On Thu, Mar 16, 2017 at 8:35 AM, David Blaikie <dblaikie at gmail.com> wrote:> Any idea of the quality/completeness of the gdb_index support? I've > started using gdb_index recently (reduces GDB startup time for Clang from > 50 seconds to 3 seconds - though I haven't measure how much it increases > link time*) & it's really handy. Would love to have some assurance it's > expected to work for LLD. > > Simple experiments seem to indicate that it's OK/good. Though a quick > llvm-dwarfdump of gdb_index between the two linkers shows about a 10% > disparity in size (LLD's is smaller) given the same inputs. (219MB v 196MB > of text dumped - I didn't compare the actual section sizes) > > *though honestly I'd be willing to trade startup time for link time 1:1 > even, because builds/links are already long enough that I go off and do > something else - whereas getting GDB start down to 3 seconds, I can start > writing my breakpoint command, etc, in those 3 seconds and be all but > unaffected by it - at 50 seconds I basically have to go off and do > something else/context switch/etc. > > On Tue, Mar 14, 2017 at 11:40 AM Rui Ueyama via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi all, >> >> LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for production >> use at least for x86-64 (and probably for AArch64 and MIPS). I believe >> you've heard a few good news about the linker -- it just works >> <http://lld.llvm.org/#features> and is very fast >> <http://lld.llvm.org/#performance>, clean, compact and supported by the >> active community. I don't think I need to reiterate why having a good >> linker is important for us as the LLVM community. >> >> There's one thing you can help us without writing even a line of code. >> Please use it! >> >> Using LLD to link LLVM/clang/etc is easy. You need to check out the LLD >> repository just like you probably already did for clang, build it, and then >> install it. LLD will be installed as ld.lld (and it won't be used by >> default.) After that, re-run cmake with -DLLVM_ENABLE_LLD=On along with >> your usual options so that LLD will be used to build LLVM. >> >> For the details of the build process, please see >> http://lld.llvm.org/#build. >> >> Thanks, >> Rui >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170316/c7d662ce/attachment.html>
Hi Rui, Are there any plans to support the -defsym command line option? Regards Michael> Hi all, > > LLVM 4.0.0 is out, and I can say that LLD/ELF is now ready for > production use at least for x86-64 (and probably for AArch64 and > MIPS). I believe you've heard a few good news about the linker -- it > just works <http://lld.llvm.org/#features> and is very fast > <http://lld.llvm.org/#performance>, clean, compact and supported by > the active community. I don't think I need to reiterate why having a > good linker is important for us as the LLVM community. > > There's one thing you can help us without writing even a line of code. > Please use it! > > Using LLD to link LLVM/clang/etc is easy. You need to check out the > LLD repository just like you probably already did for clang, build it, > and then install it. LLD will be installed as ld.lld (and it won't be > used by default.) After that, re-run cmake with -DLLVM_ENABLE_LLD=On > along with your usual options so that LLD will be used to build LLVM. > > For the details of the build process, please see > http://lld.llvm.org/#build. > > Thanks, > Rui > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170320/960029c3/attachment.html>
Rafael Avila de Espindola via llvm-dev
2017-Mar-20 13:16 UTC
[llvm-dev] Please dogfood LLD
Michael Johnson via llvm-dev <llvm-dev at lists.llvm.org> writes:> Hi Rui, > > Are there any plans to support the -defsym command line option?It doesn't look that hard, it was just never requested. What project is using it? Cheers, Rafael