<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Mar 26, 2014, at 2:56 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><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 class=""><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>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><br></div><div>-Nick</div><div><br></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><div class=""><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; position: static; z-index: auto;"> 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></div><br></div>
</blockquote></div><br></div></div>
</blockquote></div><br></body></html>