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

[Rui Ueyama]

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.

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