<div dir="ltr">I'm sorry for not updating the thread -- I thought I did that before.<div><br></div><div>I started experimenting the idea by implementing a minimal linker using the section-based design with some additional simplification/optimizations. It's already able to link small programs like the LLD itself, and the performance looks indeed better (probably the LLD is too small as a benchmark, but the new one is more than 2x faster). I also believe that the code is more readable than the current COFF port.</div><div><br></div><div>I've just hacked it up, so it needs time to clean up. I think I can send a patch for review this week.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 12:38 PM, Lang Hames <span dir="ltr"><<a href="mailto:lhames@gmail.com" target="_blank">lhames@gmail.com</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">Hi Rui,<div><br></div><div>I'd like to preserve the native format, and I'm happy to own it. I'm still getting up to speed on LLD though, so it may take me a little while to improve the tooling/testing for it.</div><div><br></div><div>Cheers,</div><div>Lang.</div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 7, 2015 at 1:28 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</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"><div class="gmail_extra"><div class="gmail_quote"><span>On Thu, May 7, 2015 at 12:58 PM, Jim Grosbach <span dir="ltr"><<a href="mailto:grosbach@apple.com" target="_blank">grosbach@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">Hi Rui,<div><br></div><div>Thank you for clarifying. This is very helpful.</div><div><br></div><div>It’s unfortunate that you’re not seeing benefits from the increased semantic knowledge the atom based model can provide. I know you’ve explored the issue thoroughly, though, so I understand why you’re wanting to move a different direction for your platform.</div><div><br></div><div>It’s reasonable to me to split the logic along atom based vs. section based in the LLD codebase. Ideally I’d love for that not to be so, but the practical results indicate that it is. I agree there is still worthwhile code sharing that can and should be done between the two. We’re talking about expanding the LLD project’s scope to include multiple linking models, not forking the project.</div><div><br></div><div>It will be important to keep the layering here such that the linking model choice is orthogonal to the file format choice. It should be possible to construct both an atom based ELF linker and a section based Mach-O linker, for example, even though the default choice for both formats is the other way around. That way different platforms with different constraints, such as what Alex talked about earlier, can make the choice of model and the choice of representation independently.</div><div><br></div><div>As a second step, I would very much like to see the native format brought back, if only for the atom-based model. Do you feel this is doable?</div></div></blockquote><div><br></div></span><div>Yes, it's doable, but I'd really like to see this back with different unit tests because the way the feature was tested was unrealistic and hard to maintain. Previously, we tested the feature by dumping intermediate linker state to a Native file and reading it back from a file to resume processing. That was different from the expected use case, which is to use Native files as an alternative object file format. Creating a checkpoint file of the linker state is a different feature (and I guess nobody really intended to implement such feature.)</div><div><br></div><div>I think we need to extend yaml2obj tool to write outputs in the Native format, and use the tool to feed Native object files to the linker.</div><div><br></div><div>Is there anyone who wants to own the feature? Or I could just revive the code, but I'd really want to avoid doing that if that doesn't come with a good test...</div><div><div><div><br></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"><span><font color="#888888"><div><br></div><div>-Jim</div></font></span><div><br><div><blockquote type="cite"><div><div><div>On May 6, 2015, at 2:18 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:</div><br></div></div><div><div><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">I'm sorry if my suggestion gave an impression that I disregard the Mach-O port of the LLD linker. I do care about Mach-O. I do not plan to break or remove any functionality from the current Mach-O port of the LLD. I don't propose to remove the atom model from the linker as long as it seems to be a good fit for the port (and looks like it is).</div><div class="gmail_quote"><br></div><div class="gmail_quote">As to the proposal to have two different linkers, I'd think that that's not really a counter-proposal, as it's similar to what I'm proposing.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Maybe the view of "future file formats vs the existing formats" (or "experimental platform vs. practical tool") is not right to get the difference between the atom model and the section model, since the Mach-O file an existing file format which we'd want to keep to be on the atom model. I think we want both even for the existing formats.</div><div class="gmail_quote"><br></div><div class="gmail_quote">My proposal can be read as suggesting we split the LLD linker into two major parts, the atom model-based and the section model-based, while keeping the two under the same project and repository. I still think that we can share code between the two, especially for the LTO, which is I prefer to have the two under the same repository.</div><div class="gmail_quote"><br></div><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>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><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.  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><font color="#888888"><div><br></div><div>-Chris</div><div><br></div></font></span></div></blockquote></div><br></div></div></div></div><span>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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></span></div></blockquote></div><br></div></div></blockquote></div></div></div><br></div></div>
<br>_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">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></div></blockquote></div><br></div>