<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 3/26/2014 5:55 PM, Nick Kledzik
wrote:<br>
</div>
<blockquote
cite="mid:9936AA00-9D8F-4753-89F0-B288284857D6@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<br>
<div>
<div>On Mar 26, 2014, at 3:37 PM, Rui Ueyama <<a
moz-do-not-send="true" 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 3:09 PM,
Nick Kledzik <span dir="ltr"><<a
moz-do-not-send="true"
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:56 PM, Rui Ueyama
<<a moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a> <span
dir="ltr"><<a
moz-do-not-send="true"
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>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>
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 class="moz-txt-link-freetext" href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121022/154212.html">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>
<br>
Thanks<br>
<br>
Shankar Easwaran<br>
<br>
<br>
<br>
<pre class="moz-signature" cols="72">--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation</pre>
</body>
</html>