<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 4, 2015 at 12:52 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="">On May 1, 2015, at 12:31 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:</span><span class=""><div><blockquote type="cite"><div><div dir="ltr"><span><div style="margin-top:0pt;margin-bottom:0pt"><span style="line-height:20.2399997711182px;white-space:pre-wrap"><font size="4"><b>Proposal</b>
</font></span></div><ol><li><font size="4"><span style="font-size:14.6666669845581px;line-height:20.2399997711182px">Re-architect the linker based on the section model where it’s appropriate.</span><br></font></li><li><font size="4"><span style="font-size:14.6666669845581px;line-height:20.2399997711182px">Stop simulating different linker semantics using the Unix model. Instead, directly implement the native behavior.</span></font></li></ol></span></div></div></blockquote></div></span><div>Preface: I have never personally contributed code to LLD, so don’t take anything I’m about to say too seriously.  This is not a mandate or anything, just an observation/idea.</div><div><br></div><div><br></div><div>I think that there is an alternative solution to these exact same problems.  What you’ve identified here is that there are two camps of people working on LLD, and they have conflicting goals:</div><div><br></div><div>- Camp A: LLD is infrastructure for the next generation of awesome linking and toolchain features, it should take advantage of how compilers work to offer new features, performance, etc without deep concern for compatibility.</div><div><br></div><div>- Camp B: LLD is a drop in replacement system linker (notably for COFF and ELF systems), which is best of breed and with no compromises w.r.t. that goal.</div><div><br></div><div><br></div><div>I think the problem here is that these lead to natural and inescapable tensions, and Alex summarized how Camp B has been steering LLD away from what Camp A people want.</div></div></blockquote><div><br></div><div>I don't think this is correct.</div><div><br></div><div>The only reason we should be having a major split along Camp A and Camp B like you describe is in the face of a concrete "compatibility" feature that *absolutely cannot* be implemented without sacrificing a modular, library-based, well-architected design. That is not what this thread is about, so I don't think your split is accurate.<br></div><div><br></div><div>I think it has merely been *forgotten* that it would be useful to have an infrastructure rather than "main() in a library", or even "main() in a separate binary"!. This is the LLVM ethos (as I'm sure you know far better than I ;).</div><div><br></div><div>Both LLVM and Clang prove that hard problems with significant "compatibility" concerns can be tackled and top-tier in-production QoI achieved while still upholding a high standard of external reusability that allows novel uses. Given what LLVM and Clang have been able to absorb (x86 ISA? C++? MSVC inline asm?) without fundamentally destabilizing their modular design, I think that we can do a bit better with LLD before throwing in the towel and cleaving it into a "compatibility" and "shiny" part.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>  This isn’t bad in and of itself, because what Camp B wants is clearly and unarguably good for LLVM.  However, it is also not sufficient, and while innovation in the linker space (e.g. a new “native” object file format generated directly from compiler structures) may or may not actually “work” or be “worth it”, we won’t know unless we try, and that won’t fulfill its promise if there are compromises to Camp B.</div><div><br></div><div>So here’s my counterproposal: <b>two different linkers.</b></div><div><br></div><div>Lets stop thinking about lld as one linker, and instead think of it is two different ones.  We’ll build a Camp B linker which is the best of breed section based linker.  It will support linker scripts and do everything better than any existing section based linker.  The first step of this is to do what Rui proposes and rip atoms out of the model.</div><div><br></div><div>We will <b>also</b> build a no-holds-barred awesome atom based linker that takes advantage of everything it can from LLVM’s architecture to enable innovative new tools without worrying too much about backwards compatibility.</div><div><br></div><div>These two linkers should share whatever code makes sense, but also shouldn’t try to share code that doesn’t make sense.  The split between the semantic model of sections vs atoms seems like a very natural one to me.</div><div><br></div><div>One question is: does it make sense for these to live in the same lld subproject, or be split into two different subprojects?  I think the answer to that question is driven from whether there is shared code common between the two linkers that doesn’t make sense to sink down to the llvm subproject itself.</div><div><br></div><div>What do you think?</div><span class=""><font color="#888888"><div><br></div><div>-Chris</div><div><br></div></font></span></div><br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
<br></blockquote></div><br></div></div>