<div dir="ltr">I think many common parts are already factored out as libObject or libLTO, so I'm not too worried about that. We should factor out even more and make linker smaller.<div><br></div><div>By common model, do you mean we should have a set of common base classes for all three linkers? I'm not sure if we can do this. I'm not against that, though. It feels to me that "having a common model makes things easier" is a unproved hypothesis, and I presented many counter examples already. At least I believe we can agree that the current model doesn't work as the one. Maybe the new one can be the one, but we are not sure yet. I hope it sets a common model, but I'm also okay with sharing less code if it makes sense overall. We need to experiment. The first try to set a common model didn't seem successful, at least.</div><div><br></div><div>Did you read the existing code and the new one? In general terms, I'd totally agree with you. What you are saying is a good engineering practice. However, as I said, I tried hard to refactor that already for months or maybe over a year continually and came to this kind of depressing conclusion. If you hack on the existing LLD and the new one, I believe you would understand the point.</div><div><br></div><div>(One interesting story would be that I tried to add LTO to LLD a few months ago but couldn't make it because it took too much time because of the complexity (and that was the final push to make me think that was not going to work), and then Peter came in and wrote up the first LTO patch for the new COFF linker pretty quickly. Peter knows far more than me about LTO for sure, but still it means something.)<div><div><br></div><div>I believe we should be careful about applying compiler's analogy to linkers. They are pretty different.</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 29, 2015 at 9:06 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@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"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, May 29, 2015 at 8:29 PM, James Y Knight <span dir="ltr"><<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.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"><span><br>
On May 29, 2015, at 10:08 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:<br>
> Large part of the difficulties in development of the current LLD comes from over-generalizataion to share code between pretty much different file formats.<br>
<br>
</span>ISTM the problem that's been described isn't that code is shared between file formats, but that an internal representation was chosen based on what MachO required, which in the end turned out to be unsuitable for representing the greater generality allowed by the other two file formats.<br>
<br>
You state that the goal is to use this new model for ELF too, assuming it proves itself worthy. Will ELF and COFF not share most of the core of the code at that point?<br>
<br>
And once COFF and ELF are taken care of, do you not think the new model will be suitable for MachO, too? It seems to me that it ought to be able to handle MachO's needs just fine, with a suitable division of MachO sections into "Chunk"s.<br>
<br>
Perhaps once everything is said and done, lld can once again have a single core model. I think that may be what Sean was trying to get at -- not that it's wrong to create a new model as a base, but that the expectation should be that new model will be _the_ model used in LLD, not a second model to be kept permanently alongside the current "single-symbol-per-atom" model, which has been shown insufficient.<br></blockquote><div><br></div></div></div><div>I couldn't have said it better myself.</div><div><br></div><div>Looking at the bigger picture, without some sort of commonality factored across all 3 formats in LLD, it is very difficult for the LLVM project to deliver useful innovations consistently across platforms. Without a common model, we are limited to a patchwork of platform-specific hacks; with a common model, we can think about new features at a higher level and deliver them consistently.</div><div><br></div><div>The situation is very analogous to the reason why it is a good idea to have the LLVM IR in the middle-end. The LLVM IR is not target-agnostic; but the target-specific aspects are managed in more-or-less controlled fashion that allows thinking about certain things at a higher level.</div><span class="HOEnZb"><font color="#888888"><div> </div><div>-- Sean Silva </div></font></span></div><br></div></div>
</blockquote></div><br></div>