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>
On Wed, Mar 15, 2017 at 11:14 PM, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > > 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. >I agree with Sean, that doesn't sound right. Not only I do LTO with mixed versions of lld and LLVM several hundreds of times per week, but when lld wasn't still so popular I was able to do LTO of the FreeBSD base system almost entirely without seeing any SIGSEGV at startup in the linked applications. In other words, this should just work, and if it doesn't it's a legitimate bug (and I'll appreciate if you can report it upstream).
On 16 Mar 2017, at 06:14, Sean Silva <chisophugis at gmail.com> wrote:> > 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.It appears that I’d misdiagnosed the problem. Even with matching versions, I get a non-functional tablegen for a thin LTO build on FreeBSD, but when I set them to identical versions CMake had failed to pick up the LTO instruction and so was doing a normal non-LTO build. David
On 16 March 2017 at 02:14, Sean Silva via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > I would not be > surprised by older LLD and newer Clang causing issues, but the reverse > Should Work.We'll soon have cases where there will be a LLD 4.0.0 /usr/bin/ld provided by the base system, and Clang 4.1.0 /usr/local/bin/clang installed from a package. It probably means we just need to have that Clang use its own copy of LLD in the same package. It'll be great if we can detect and error on this case rather than producing broken output though.
On Thu, Mar 16, 2017 at 1:07 AM, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote:> On 16 Mar 2017, at 06:14, Sean Silva <chisophugis at gmail.com> wrote: >> >> 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. > > It appears that I’d misdiagnosed the problem. Even with matching versions, I get a non-functional tablegen for a thin LTO build on FreeBSD, but when I set them to identical versions CMake had failed to pick up the LTO instruction and so was doing a normal non-LTO build. >Any chances you can report the llvm-tblgen failure? I built that all the time (even with ThinLTO and I've never seen it, so I'm a little surprised). -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare
I agree, it seems like we ought to be installing and looking for lld as
part of the compiler install directory (for example,
/usr/lib/llvm-4.0/bin/{clang,lld}), rather than searching for it in the
base system.
On Thu, Mar 16, 2017 at 2:31 PM, Ed Maste via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 16 March 2017 at 02:14, Sean Silva via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > I would not be
> > surprised by older LLD and newer Clang causing issues, but the reverse
> > Should Work.
>
> We'll soon have cases where there will be a LLD 4.0.0 /usr/bin/ld
> provided by the base system, and Clang 4.1.0 /usr/local/bin/clang
> installed from a package. It probably means we just need to have that
> Clang use its own copy of LLD in the same package.
>
> It'll be great if we can detect and error on this case rather than
> producing broken output though.
> _______________________________________________
> 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/e81aed27/attachment.html>