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

[Rui Ueyama]

On Wed, Mar 26, 2014 at 3:55 PM, Nick Kledzik <kledzik at apple.com> 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.
>

He's been cc'ed so I hope he'll reply soon. :)


> -Nick
>
>
>>    If in LayoutPass, compareAtomsSub() was enhanced to sort sections,
>>>> then all COFF would need to do is have .text$a sort before .text$b and then
>>>> atoms would be all laid out in the order you want.  The COFF Writer could
>>>> then ignore the trailing $blah and put the range of atoms from all .text$*
>>>> sections into one .text section.
>>>>
>>>
>>> Basically agree. Current LayoutPass wouldn't work for the COFF suffix
>>> rule because compareAtomsSub() currently does not sort atoms by section
>>> name. However adding such rule seems to be trivial.
>>>
>>>
>>>>   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.
>>>>
>>>> http://llvm-reviews.chandlerc.com/D3164
>>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140326/cbbe699a/attachment.html>