[llvm-dev] Please dogfood LLD

Davide Italiano via llvm-dev llvm-dev at lists.llvm.org
Wed Mar 15 23:51:15 PDT 2017


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).


More information about the llvm-dev mailing list