Andrew Kelley via llvm-dev
2016-Dec-14 04:10 UTC
[llvm-dev] LLD status update and performance chart
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? 2. How close is the LLD project to reaching that state? 3. Is there anything preventing "main() in a library" from supporting all of these platforms and architectures? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/0830d8b5/attachment.html>
Sean Silva via llvm-dev
2016-Dec-14 04:41 UTC
[llvm-dev] LLD status update and performance chart
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. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161213/791bc59d/attachment.html>
Gleb Popov via llvm-dev
2016-Dec-14 07:07 UTC
[llvm-dev] LLD status update and performance chart
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>