<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Mar 26, 2014 at 5:42 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><div><div class="h5">
<div>On 3/26/2014 7:19 PM, Rui Ueyama wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Mar 26, 2014 at 4:53 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>
<div>On 3/26/2014 6:25 PM, Rui Ueyama wrote:<br>
</div>
<blockquote type="cite">
<pre>On Wed, Mar 26, 2014 at 4:11 PM, Shankar Easwaran
<a href="mailto:shankare@codeaurora.org" target="_blank"><shankare@codeaurora.org></a>wrote:
</pre>
<blockquote type="cite">
<pre> On 3/26/2014 5:55 PM, Nick Kledzik wrote:
On Mar 26, 2014, at 3:37 PM, Rui Ueyama <a href="mailto:ruiu@google.com" target="_blank"><ruiu@google.com></a> wrote:
On Wed, Mar 26, 2014 at 3:09 PM, Nick Kledzik <a href="mailto:kledzik@apple.com" target="_blank"><kledzik@apple.com></a> wrote:
</pre>
<blockquote type="cite">
<pre> On Mar 26, 2014, at 2:56 PM, Rui Ueyama <a href="mailto:ruiu@google.com" target="_blank"><ruiu@google.com></a> wrote:
On Wed, Mar 26, 2014 at 2:51 PM, Nick Kledzik <a href="mailto:kledzik@apple.com" target="_blank"><kledzik@apple.com></a>wrote:
</pre>
<blockquote type="cite">
<pre> On Mar 26, 2014, at 2:44 PM, Rui Ueyama <a href="mailto:ruiu@google.com" target="_blank"><ruiu@google.com></a> wrote:
On Wed, Mar 26, 2014 at 2:23 PM, <a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a> <a href="mailto:kledzik@apple.com" target="_blank"><kledzik@apple.com></a>wrote:
</pre>
<blockquote type="cite">
<pre> Given your description of COFF, I'm not sure follow-on
atom/references is the right model.
We probably want a way to order sections. For instance, the darwin
linker automatically arranges sections for best performance.
</pre>
</blockquote>
<pre> 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.
The darwin linker very much dead strips and re-orders mach-o at the
atom level.
</pre>
</blockquote>
<pre> 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.
The call instruction has a relocation on it, so if the target moves
(relatively), the linker updates the call instruction.
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.
</pre>
</blockquote>
<pre> 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.
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?
You’ll have to ask Shankar what problem he was trying to solve with the
layout before/after stuff.
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
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.
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.
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>
I would like to have the kindLayoutBefore/kindLayoutAfter/kindInGroup
references to exist and do the functionalities that it is trying to
accomplish.
This could be used when we want to implement the order file in the near
future.
</pre>
</blockquote>
<pre>Is there anything that is presently depending on layout-after and in-group,
which does not work with the default ordering function, compareAtomsSub()?
I don't intend to say that that wouldn't be needed for ELF, but just trying
to understand.
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.</pre>
</blockquote>
</div>
</div>
Tell me another way to accomplish the same thing that I
would want to order atoms with a linker script ?<br>
<br>
How can I make sure the section that contains the atoms
are moved as a group without this change ?<br>
</div>
</blockquote>
<div><br>
</div>
<div>That's what I'm asking. If some feature is needed for
some ELF linker script feature, we need to implement or
keep it, so I wanted to know actual examples. Also, what
I'm asking in the first sentence is about the current
implementation of ELF support in LLD.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote></div></div>
The current functionality thats tested in the tree, uses
kindLayoutAfter/kindInGroup only to model ELF in lld. Its only used
to model ELF sections.<br>
<br>
I use it in environments <b>internally</b> that reads gprof data
and see if it arranges <b>atoms</b> appropriately, which make use
of this functionality.</div></blockquote><div><br></div><div>If you need some feature for your internal organization use only and do not upstream, I'd think that use cannot justify keeping that functionality in upstream in general.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><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">
<div text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">
<pre>Specifically, layout-before relationship is not really needed for ay
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.</pre>
</blockquote>
I think I have said many times as well, again ELF uses <b>only</b>
layout-after and in-group.<br>
<br>
You cannot model weak symbols with just layout-after
reference alone. You cannot have a Layout After
reference to a weak symbol, as when the weak symbol
could be overridden.<br>
<br>
To make function alias symbols, ELF needs
kindLayoutBefore reference, so that the linker can
easily setup an alias to a function(the +afs option).<br>
<br>
The alias symbols are again zero sized symbols that are
defined through the command-line.</div>
</blockquote>
<div><br>
</div>
<div>I don't see the reason why you can't use
kindLayoutAfter instead of kindLayoutBefore to enforce
layout in that case. In order to create a layout-before
edge from atom A to B, you need to have references both to
A and B. So adding "layout-before A" edge to B is as easy
as adding "layout-after B" edge to B.</div>
<div><br>
</div>
<div>For example, if you already have A -> B ("->"
means "layout-after") and want to add X (zero size atom)
as an alias for A, you can insert X after A, so that the
resulting graph looks like A -> X -> B. It can also
be represented as A -> B and B => X ("=>" means
"layout-before"). My point is that we can choose either of
two, but the former is simpler.</div>
<div><br>
</div>
<div>I'm not suggesting we remove in-group or layout-after.
I'm against keep supporting layout-before in the layout
pass.</div>
<div><br>
</div>
</div>
</div>
</div>
</blockquote></div>
Its much easier to do with kindLayoutBefore. Its easy to handle if
its an alias to a section symbol, which exists as the first symbol
in the section. <br>
<br>
The only thing I wanted to say is <b>not </b>to remove/fix the
infiniteloop for kindLayoutBefore functionality as things become
much easier.<br>
<br>
Just mentioning, In your example, A->X->B produces an alias to
B (X and B would share the same address), we need X->A->B.<br></div></blockquote><div><br></div><div>It's much easier to do with layout-before, because we have a complex piece of code in LayoutPass.cpp for that feature. That simplicity of use is not free.</div>
<div><br></div><div>Layout-before is overly flexible mechanism, and its feature overlaps too much with layout-after. If you want to use layout-before for symbol aliases, you could define new kind of relationship between symbols, say "alias" relationship, to layout them at the same offset. That would be much easier to implement in the layout pass, and it should be as easy to use as layout-before. I don't still see the reason we really need layout-before and no other mechanisms.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<--snip from earlier message from Nick--><div class=""><br>
<pre> 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.</pre>
</div>
<--end snip from earlier message from Nick--><br>
<br>
We should plan to do the above, as the suggestion from Nick should
greatly improve performance, which is the most concerning point.<br>
<br>
PS: Overloading kindLayoutBefore just for garbage collection, is
something that you may want to think of changing in your patch (If
you intend to use LayoutBefore references).<div class=""><br>
<br>
Thanks<br>
<br>
Shankar Easwaran<br>
<pre cols="72">--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation</pre>
</div></div>
</blockquote></div><br></div></div>