[llvm-dev] LLD status update and performance chart

[Gleb Popov via llvm-dev]

On Wed, Dec 14, 2016 at 7:41 AM, Sean Silva via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Tue, Dec 13, 2016 at 8:10 PM, Andrew Kelley <superjoe30 at gmail.com>
> wrote:
>
>>
>> On Tue, Dec 13, 2016 at 10:59 PM, Sean Silva via llvm-dev <
>> llvm-dev at lists.llvm.org> wrote:
>>>
>>> Yes. Rui has bent over backwards every time a real user has come to us
>>> and said "we need X". The historical precedent here is that LLD is open to
>>> many kinds of changes, but not on theoretical grounds.
>>>
>>> Admittedly this leads to a somewhat conservative design for the linker
>>> w.r.t. enabling new use cases. However, having been involved directly or
>>> indirectly with LLD development over the last 4 or 5 years, the number of
>>> new use cases that have been proposed fall into a very small number of
>>> categories:
>>>
>>> - I want to have "main() in a library" for a static linker. LLD/ELF
>>> currently provides this functionality (with some unfortunate caveats w.r.t.
>>> re-entrancy and other stuff, but the core functionality is there, and LLD
>>> has catered to reasonable requests to remove or mitigate the caveats).
>>>
>>
>> My previous understanding is that LLD is a drop in replacement for every
>> system linker - COFF, ELF, MACH-O, for every architecture that LLVM
>> supports.
>>
>> 1. Is what I said above in the scope of the LLD project?
>>
>
> That is certainly in scope.
>
>
>>
>> 2. How close is the LLD project to reaching that state?
>>
>
> To varying degrees.
>
> COFF: LLD can self-host and also build chromium and is generally
> considered a stable windows linker. For windows-specific reasons, debug
> info (PDB) is particularly challenging and still being worked on. Without
> something like the big open-source package managers on ELF platforms it's
> harder to perform really thorough testing of the long tail of issues though.
>

KDE has Craft system that compiles all opensource dependencies and KDE
itself on Windows. I've used it to test clang-cl.exe, for instance (which
turned out to be pretty successful - clang-cl compiled whole Qt + various
deps + KDE Frameworks + some KDE Apps, and there was only few problems). I
bet it shouldn't be too hard to hook LLD into that.

ELF: LLD is a respectable linker basically on par with gold for most use
> cases. And LLD is even beyond gold for some things; for example, gold can't
> link a working FreeBSD kernel and LLD can (on the other hand, gold can link
> a working Linux kernel, and I don't think LLD can yet; if somebody is
> interested in working on this, I can share how Michael and I debugged the
> issues with the mislinked FreeBSD kernel, which involved bootloader
> debugging and other stuff). There's a tail of features being worked on, but
> you can use it now.
> MachO: There is relatively little activity upstream, but last I talked
> with Lang, it is progressing nicely. He can probably give more precise
> status info. I don't remember if it can self-host yet.
>
>
>
>>
>> 3. Is there anything preventing "main() in a library" from supporting all
>> of these platforms and architectures?
>>
>>
> All 3 already provide this. If you look in main() in lld/tools/lld/lld.cpp
> you can see the corresponding calls to {elf,coff,mach_o}::link. There are
> some caveats for ELF and especially COFF. Basically, the ELF and COFF ones
> are not re-entrant currently, and the COFF one currently uses fatal error
> handling for common errors (ELF did too, but a user requested that it not
> do so and it was fixed).
>
> -- Sean Silva
>
> _______________________________________________
> 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/20161214/36f55ded/attachment.html>