<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 28, 2015, at 5:42 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I guess, looking back at Nick's comment:</div><div><br></div><div>"<span style="font-size:12.8000001907349px">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."</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">it seems that the primary issue on the ELF/COFF side is that currently the LLVM backends are taking a finer-grained atomicity that is present inside LLVM, and losing information by converting that to a coarser-grained atomicity that is the typical "section" in ELF/COFF.</span></div><div><span style="font-size:12.8000001907349px">But doesn't -ffunction-sections -fdata-sections already fix this, basically?</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">On the Mach-O side, the issue seems to be that Mach-O's notion of section carries more hard-coded meaning than e.g. ELF, so at the very least another layer of subdivision below what Mach-O calls "section" would be needed to preserve this information; currently symbols are used as a bit of a hack as this "sub-section" layer.</span></div></div></div></div></blockquote><div>I’m not sure what you mean here.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">So the problem seems to be that the transport format between the compiler and linker varies by platform, and each one has a different way to represent things, some can't represent everything we want to do, apparently.</span></div></div></div></div></blockquote><div>Yes!</div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><span style="font-size: 12.8000001907349px;">BUT it sounds like at least relocatable ELF semantics can, in principle, represent everything that we can imagine an "atom-based file format"/"native format" to want to represent. </span><span style="font-size: 12.8000001907349px;">Just to play devil's advocate here, let's start out with the "native format" being relocatable ELF - on *all platforms*. Relocatable object files are just a transport format between compiler and linker, after all; who cares what we use? If the alternative is a completely new format, then bootstrapping from relocatable ELF is strictly less churn/tooling cost.</span></div><div><br></div><div><span style="font-size:12.8000001907349px">People on the "atom side of the fence", what do you think? Is there anything that we cannot achieve by saying "native"="relocatable ELF"?</span><span style="font-size:12.8000001907349px"><br></span></div></div></div></div></blockquote></div><div>1) Turns out .o files are written once but read many times by the linker. Therefore, the design goal of .o files should be that they are as fast to read/parse in the linker as possible. Slowing down the compiler to make a .o file that is faster for the linker to read is a good trade off. This is the motivation for the native format - not that it is a universal format.</div><div><br></div><div>2) I think the ELF camp still thinks that linkers are “dumb”. That they just collate .o files into executable files. The darwin linker does a lot of processing/optimizing the content (e.g. Objective-C optimizing, dead stripping, function/data re-ordering). This is why atom level granularity is needed.</div><div><br></div><div>For darwin, ELF based .o files is not interesting. It won’t be faster, and it will take a bunch of effort to figure out how to encode all the mach-o info into ELF. We’d rather wait for a new native format.</div><div><br></div><div>-Nick</div><div><br></div></body></html>