[PATCH] Do not use layout-before to layout atoms.
shankare at codeaurora.org
Wed Mar 26 16:53:13 PDT 2014
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 :
>> I would like to have the kindLayoutBefore/kindLayoutAfter/kindInGroup
>> references to exist and do the functionalities that it is trying to
>> This could be used when we want to implement the order file in the near
> 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
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits