<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 14, 2016 at 7:41 AM, Sean Silva via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Tue, Dec 13, 2016 at 8:10 PM, Andrew Kelley <span dir="ltr"><<a href="mailto:superjoe30@gmail.com" target="_blank">superjoe30@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote"><span class="m_-7786163491889852990gmail-">On Tue, Dec 13, 2016 at 10:59 PM, Sean Silva via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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:</div><div class="gmail_extra"><br></div><div class="gmail_extra">- 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).</div></div></blockquote><div><br></div></span><div>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.</div><div><br></div><div>1. Is what I said above in the scope of the LLD project?</div></div></div></div></blockquote><div><br></div></span><div>That is certainly in scope.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>2. How close is the LLD project to reaching that state?</div></div></div></div></blockquote><div><br></div></span><div>To varying degrees.</div><div><br></div><div>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.</div></div></div></div></blockquote><div><br></div><div>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.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.</div><div>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.</div><span class=""><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>3. Is there anything preventing "main() in a library" from supporting all of these platforms and architectures?</div></div><br></div></div>
</blockquote></span></div><br></div><div class="gmail_extra">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).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">-- Sean Silva</div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>