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

[Shankar Easwaran]

On 3/26/2014 5:55 PM, Nick Kledzik wrote:
>
> On Mar 26, 2014, at 3:37 PM, Rui Ueyama <ruiu at google.com 
> <mailto:ruiu at google.com>> wrote:
>
>> On Wed, Mar 26, 2014 at 3:09 PM, Nick Kledzik <kledzik at apple.com 
>> <mailto:kledzik at apple.com>> wrote:
>>
>>
>>     On Mar 26, 2014, at 2:56 PM, Rui Ueyama <ruiu at google.com
>>     <mailto:ruiu at google.com>> wrote:
>>
>>>     On Wed, Mar 26, 2014 at 2:51 PM, Nick Kledzik <kledzik at apple.com
>>>     <mailto:kledzik at apple.com>> wrote:
>>>
>>>
>>>         On Mar 26, 2014, at 2:44 PM, Rui Ueyama <ruiu at google.com
>>>         <mailto:ruiu at google.com>> wrote:
>>>
>>>>         On Wed, Mar 26, 2014 at 2:23 PM, kledzik at apple.com
>>>>         <mailto:kledzik at apple.com> <kledzik at apple.com
>>>>         <mailto: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.

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/d9a988ca/attachment.html>