<div dir="ltr">It is not a secondary goal for me to create a linker that works very well with existing file formats. I'm trying to create a practical tool with clean codebase and with the LLVM library. So I can't agree with you that it's secondary.<div><br></div><div>I don't also share the view that we are trying to solve the problem that's solved in '70s. How fast we can link a several hundred megabyte executable is, for example, a pretty modern problem that we have today.</div><div><br></div><div>I don't oppose to the idea of creating a new file format that you think better than the existing ones. We may come up with a better design, implement that to the compiler, set out the foundation, and create a linker based on that. However, what's actually happening is coming up with a new idea which is not necessarily best to represent existing file formats, set out the foundation based on that idea, and let LLD developers create a linker for the existing formats base on the foundation (which is, again, is not suitable for the formats). And there was no efforts made in the recent few years for "the new format". I have to say that something is not correct here.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, May 3, 2015 at 1:50 PM, Alex Rosenberg <span dir="ltr"><<a href="mailto:alexr@leftfield.org" target="_blank">alexr@leftfield.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="">On May 1, 2015, at 7:06 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:<br></span><div><span class=""><br><blockquote type="cite"><div style="font-family:Helvetica;font-size:10px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div dir="ltr"><div class="gmail_quote">On Fri, May 1, 2015 at 6:46 PM Nick Kledzik <<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>> 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"><br><div><div>On May 1, 2015, at 12:31 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:</div><blockquote type="cite"><b style="font-family:Helvetica;font-size:15px;font-style:normal;font-variant:normal;letter-spacing:normal;line-height:20px;text-align:start;text-indent:0px;text-transform:none;white-space:pre-wrap;word-spacing:0px">The atom model is not the best model for some architectures
</b></blockquote><br></div></div><div style="word-wrap:break-word">The atom model is a good fit for the llvm compiler model for all architectures.  There is a one-to-one mapping between llvm::GlobalObject (e.g. function or global variable) and lld:DefinedAtom.</div></blockquote><div><br></div><div>I'm not sure how that's really relevant.</div><div><br></div><div>On some architectures, the unit at which linking is defined to occur isn't a global object. A classic example of this are architectures that have a hard semantic reliance grouping two symbols together and linking either both or neither of them.</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>The problem is the ELF/PECOFF file format.   (Actually mach-o is also section based, but we have refrained from adding complex section-centric features to it, so mapping it to atoms is not too hard).</div><div><br></div><div>I’d rather see our effort put to moving ahead to an llvm based object file format (aka “native” format) which bypasses the impedance mismatch of going through ELF/COFF.</div></div></blockquote><div><br></div><div>We still have to be able to (efficiently) link existing ELF and COFF objects though? While I'm actually pretty interested in some better object file format, I also want a better linker for the world we live in today...</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"></blockquote></div></div></div></blockquote><div><br></div></span><div>For us, this is secondary. A major part of the reason we started lld was to embrace the atom model, that is to bring the linker closer to the compiler. We have a lot of long-term goals that involve altering the traditional compiler/linker flow, with a goal toward actual improvements in developer workflow. Just iterating again on the exact same design we've had since the '70s is not good enough.</div><div><br></div><div>The same is true of other legacy we're inheriting like linker scripts. While we want them to work and work efficiently, we should consider them part of necessary legacy to support and not make them fundamental to our internal design. This planning will allow us latitude to make fundamental improvements. We make similar decisions across LLVM all the time, take our attitude toward __builtin_constant_p() or nested functions for example.</div><div><br></div><div>We've been at this for several years. We had goals and deadlines that we're not meeting. We've abandoned several significant design points so far because Rui is making progress on PECOFF and jettisons things and we let it slide because of his rapid pace.</div><div><br></div><div>Core command line? GONE.</div><div>Round-trip testing? GONE.</div><div>Native file format? GONE.</div><div>And now we're against the Atom model?</div><div><br></div><div>I don't want a new linker that just happens to be so mired in the same legacy that we've ended up with nothing but a gratuitous rewrite with a better license.</div><div><br></div><div>We want:</div><div><br></div><div>* A new clean command line that obviates the need for linker scripts and their incestuous design requirements.</div><div>* lld is thoroughly tested, including the efficient new native object file format it provides.</div><div>* lld is like the rest of LLVM and can be remixed such that it's built-in to the Clang driver, should we choose to.</div><div>* We can have the linker drive compilation such that objects don't leave the disk cache before being consumed by the linker.</div><div><br></div><div>Perhaps we should schedule an in-person lld meeting. Almost everybody is in the Bay Area. I'm happy to host if we think this will help.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Alex</div></font></span></div></div></blockquote></div><br></div>