<div dir="ltr"><div class="gmail_quote">On Fri, May 1, 2015 at 6:46 PM Nick Kledzik <<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>> 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"><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"><div>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></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:0 0 0 .8ex;border-left:1px #ccc 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>  </div></div><div style="word-wrap:break-word"><div><br></div><div><br></div><div><br></div><div><blockquote type="cite"><b style="font-size:15px;line-height:20px;white-space:pre-wrap">One symbol resolution model doesn’t fit all</b><br></blockquote><br></div></div><div style="word-wrap:break-word"><div>Yes, the Resolver was meant to call out to the LinkingContext object to direct it on how to link.  Somehow that got morphed into “there should be a universal data model that when the Resolver process the input data, the right platform specific linking behavior falls out”.  </div></div><div style="word-wrap:break-word"><div><br></div><div><br></div><div>-Nick</div><div><br></div></div>_______________________________________________<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>
</blockquote></div></div>