[PATCH] Do not use layout-before to layout atoms.

[Shankar Easwaran]

On 3/26/2014 6:25 PM, Rui Ueyama wrote:
> On Wed, Mar 26, 2014 at 4:11 PM, Shankar Easwaran
> <shankare at codeaurora.org>wrote:
>
>>   On 3/26/2014 5:55 PM, Nick Kledzik wrote:
>>
>>
>>   On Mar 26, 2014, at 3:37 PM, Rui Ueyama <ruiu at google.com> wrote:
>>
>>    On Wed, Mar 26, 2014 at 3:09 PM, Nick Kledzik <kledzik at apple.com> wrote:
>>
>>>   On Mar 26, 2014, at 2:56 PM, Rui Ueyama <ruiu at google.com> wrote:
>>>
>>>    On Wed, Mar 26, 2014 at 2:51 PM, Nick Kledzik <kledzik at apple.com>wrote:
>>>
>>>>   On Mar 26, 2014, at 2:44 PM, Rui Ueyama <ruiu at google.com> wrote:
>>>>
>>>>    On Wed, Mar 26, 2014 at 2:23 PM, kledzik at apple.com <kledzik at apple.com>wrote:
>>>>
>>>>>    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.
>>>>>
>>>>   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.
>>>>
>>>   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.
>>>
>>   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 :
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121022/154212.html
>>
>> 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.
>>
> 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.
Tell me another way to accomplish the same thing that I would want to 
order atoms with a linker script ?

How can I make sure the section that contains the atoms are moved as a 
group without this change ?
> 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.
I think I have said many times as well, again ELF uses *only* 
layout-after and in-group.

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.

To make function alias symbols, ELF needs kindLayoutBefore reference, so 
that the linker can easily setup an alias to a function(the +afs option).

The alias symbols are again zero sized symbols that are defined through 
the command-line.

Thanks

Shankar Easwaran

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140326/c6037e80/attachment.html>