<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On May 1, 2015, at 12:31 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">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; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: pre-wrap; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">The atom model is not the best model for some architectures
</b></blockquote><br></div><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><br></div><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><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 class="Apple-interchange-newline"></blockquote><br></div><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><br></div><div><br></div><div>-Nick</div><div><br></div></body></html>