<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>