<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 26, 2014 at 4:11 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankare@codeaurora.org" target="_blank">shankare@codeaurora.org</a>></span> wrote:<br>


<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 text="#000000" bgcolor="#FFFFFF"><div>
    <div>On 3/26/2014 5:55 PM, Nick Kledzik
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <br>
      <div>
        <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: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"><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: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"><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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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>You’ll have to ask Shankar what problem he was trying to
          solve with the layout before/after stuff.</div>
        <div><br>
        </div>
      </div>
    </blockquote></div>
    ELF does not use layout-before references, it uses only layout-after
    and in-group references. The reason the ELF linker tried to do this
    was <br>
    <br>
    a) Prevent reordering of atoms and maintain section relationship.
    All atoms in a section have to be tied together. Anything that tries
    to reorder has to reorder the whole section.<br>
    b) This also would clearly model linker scripts in the future that
    moving a function would make sure the section that contains the
    function is moved, and not the individual function.<br>
    <br>
    This was earlier discussed in the thread :
<a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121022/154212.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121022/154212.html</a><br>
    <br>
    I would like to have the
    kindLayoutBefore/kindLayoutAfter/kindInGroup references to exist and
    do the functionalities that it is trying to accomplish.<br>
    <br>
    This could be used when we want to implement the order file in the
    near future.<br></div></blockquote><div><br></div><div>Is there anything that is presently depending on layout-after and in-group, which does not work with the default ordering function, <span style="font-family:arial,sans-serif;font-size:13px">compareAtomsSub()? I don't intend to say that that wouldn't be needed for ELF, but just trying to understand.</span></div>


<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">As to the feature set that LayoutPass provides, we shouldn't keep this complexity as is as I repeatedly stated, because as I sayd multiple times it seems that this level of complexity is not (and will not) needed.</span></div>


<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">Specifically, layout-before relationship is not really needed for any occasion to layout atoms -- in all cases when you want to layout atom A before B, you can just add "layout-after to A" to B instead. Dead-stripping path would still need doubly-linked graph, but it does not mean that layout-pass needs to use it too.</span></div>


<div><br></div><div>Also the piece of code handling layout-before is buggy. It sometimes falls into an infinite loop for a valid object file. Fixing it would be a waste of time if the feature is not needed.</div><div><br>


</div><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 text="#000000" bgcolor="#FFFFFF">
    Thanks<span><font color="#888888"><br>
    <br>
    Shankar Easwaran<br>
    <br>
    <br>
    <br>
    <pre cols="72">-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation</pre>
  </font></span></div>

</blockquote></div><br></div></div>