<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 28, 2015 at 6:25 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</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"><br><div><span class=""><div>On May 28, 2015, at 5:42 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com" target="_blank">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></span><div>I’m not sure what you mean here.</div><span class=""><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></span><div>Yes!</div><span class=""><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></span></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></blockquote><div><br></div><div>Whenever this has come up, Rafael has always told me that (at least in the context of ELF) that the current file format isn't a problem in this regard. Maybe you guys should talk?</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><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></blockquote><div><br></div><div>As has been mentioned elsewhere in the thread, ELF is able to represent atoms (in fact, something more general). So I guess this just leaves us with that you think that current object file formats are too slow to read? That begs for some numbers.</div><div> <br></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><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.</div></div></blockquote><div><br></div><div>I was playing devil's advocate with the concrete ELF suggestion, but I think that it wouldn't be really any different amount of effort vs encoding it in a "native" format. I mean, in the worst case you can just make a custom section in the ELF file and put whatever you want in there, while keeping the rest of the file structure for the bulk of the object. ELF has very much a "bag of bytes" approach, so layering any semantics on top should be pretty easy.</div><div><br></div><div>-- Sean Silva</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>  We’d rather wait for a new native format.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Nick</div><div><br></div></font></span></div></blockquote></div><br></div></div>