[llvm-dev] Please dogfood LLD

[Sean Silva via llvm-dev]

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>