<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 26, 2014 at 3:55 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><div class=""><div>On Mar 26, 2014, at 3:37 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 26, 2014 at 3:09 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><div><div>On Mar 26, 2014, at 2:56 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 26, 2014 at 2:51 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><div><div>On Mar 26, 2014, at 2:44 PM, Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 26, 2014 at 2:23 PM, <a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a> <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"><br>
Given your description of COFF, I'm not sure follow-on atom/references is the right model.<br>
<br>
We probably want a way to order sections. For instance, the darwin linker automatically arranges sections for best performance.<br></blockquote><div><br></div><div>Yes, follow-on atom/references model is not probably the best model for COFF. It's too fine grained. The unit of layout is not an atom (symbol) but a section. We never want to rearrange or dead-strip each atom. AFAIK so is true for ELF and Mach-O.</div>
</div></div></div></blockquote><div><br></div></div><div>The darwin linker very much dead strips and re-orders mach-o at the atom level.</div></div></div></blockquote><div><br></div><div>Maybe silly question, but how are dependencies between symbols (atoms) represented in Mach-O? I mean, if function A in .text have a relative call instructions to function B in the same .text section, both functions needs to be in the final executable keeping the same offset.</div>
</div></div></div></blockquote></div><div>The call instruction has a relocation on it, so if the target moves (relatively), the linker updates the call instruction. </div><div><br></div><div>In more detail, the linker parses the call instruction and relocation and adds to A, a Reference to B. Then everything proceeds as an atom graph, including dead stripping and re-ordering. In the writer, after atoms that remain are assigned addresses, the writer sees the reference in A to B, it knows the address of both, so it fixes up the call instruction given those final addresses.</div>
</div></div></blockquote><div><br></div><div>Thank you for the explanation. That sounds like a different semantics than COFF indeed. In COFF we don't usually have relocations within a section, so a section is a basic unit and we can't reorder or remove data in it. If you want to reorder and dead-strip each function, you have to specify /Gy (equivalent to -ffunction-section) to put each function in its own section.</div>
<div><br></div><div>Do you know if we really use layout-after's in ELF to order atoms? It seems to me that the default sorting function orders them correctly, according to atom's ordinal, file ordinal, etc. Is there any case that we are doing more than that using layout-after edges?</div>
</div></div></div></blockquote></div><div>You’ll have to ask Shankar what problem he was trying to solve with the layout before/after stuff.</div></div></div></blockquote><div><br></div><div>He's been cc'ed so I hope he'll reply soon. :)</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 class=""><div>-Nick</div><div><br></div><blockquote type="cite">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><br><blockquote type="cite">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<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><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> If in LayoutPass, compareAtomsSub() was enhanced to sort sections, then all COFF would need to do is have .text$a sort before .text$b and then atoms would be all laid out in the order you want. The COFF Writer could then ignore the trailing $blah and put the range of atoms from all .text$* sections into one .text section.<br>
</blockquote><div><br></div><div>Basically agree. Current LayoutPass wouldn't work for the COFF suffix rule because compareAtomsSub() currently does not sort atoms by section name. However adding such rule seems to be trivial.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In terms of improving performance of this pass, we could add a flag to the MergedFile that indicates if any Atom in it has a follow-on (layout before or layout after reference). If there are none (which is common for COFF and mach-o), then all the _followOnRoots and _followOnNexts set up can be skipped.<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D3164" target="_blank">http://llvm-reviews.chandlerc.com/D3164</a><br>
</blockquote></div><br></div></div>
</blockquote></div><br></div>
</blockquote></div><br></div></div>
</blockquote></div></div><br></div></blockquote></div><br></div></div>
</blockquote></div></div><br></div></blockquote></div><br></div></div>