<p dir="ltr"><br>
On May 1, 2015 9:42 PM, "Nick Kledzik" <<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>> wrote:<br>
><br>
><br>
> On May 1, 2015, at 12:31 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
>><br>
>> The atom model is not the best model for some architectures<br>
><br>
><br>
> 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.  </p>
<p dir="ltr">That is not the input to the linker and therefore irrelevant. </p>
<p dir="ltr">> 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).</p>
<p dir="ltr">The objective is to build an elf and coff linker. The input has sections and splitting them is a total waste of time and extra design complexity. </p>
<p dir="ltr">> 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.  </p>
<p dir="ltr">Absolutely not. We have to be able to handle elf and coff and do it well.</p>
<p dir="ltr">Also, gold shows that elf at least works extremely well. With function sections the compiler is in complete control of the size of the units the linker uses. With my recent work on MC the representation is also very efficient. I have no reason to believe coff is any different. </p>
<p dir="ltr">Cheers, <br>
Rafael </p>