[PATCH] Do not use layout-before to layout atoms.
kledzik at apple.com
Wed Mar 26 15:09:17 PDT 2014
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.
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits