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

[Rui Ueyama]

That's a good point and that's why I created this change. My goal is to
simplify this pass while keeping it as powerful as it needs to be. As to
simplify the code, I believe we all agree that we want to make this pass
simpler than it is for many reasons, including maintainability, speed, and
reducing number of bugs. As to how much degree we can simplify this thing,
it's not still clear.

I'd think this patch worth submitting now. This is a good first step
towards the goal, and it won't harm anything.

For COFF, we only need follow-on map to layout sections with '$" suffixes.
That is, the linker drops "$" and subsequent characters from a section name
and merges them into one section (for example, ".text$mn" will be merged to
".text"). When the linker merges them, the section contents will be sorted
in suffix order (e.g. ".text$a" will come before ".text$b" in the final
".text").


On Wed, Mar 26, 2014 at 1:13 PM, kledzik at apple.com <kledzik at apple.com>wrote:

>
>   It looks like buildPrecededByTable() will "fix" atom chains that are not
> doubly linked list.  That is, if something only has the backward links to
> it predecessor, the layout will still work.  So, assuming everything has
> both links, I can see removing buildPrecededByTable() shouldn't break
> anything.
>
>   But first it would be good to know where this is going.  What is the
> better long term design?
>
>   Also, I'm not sure this pass needs this complexity for what ELF needs.
>  The darwin linker needs the follow-on map, but only when using an "order
> file" (a file with a list of symbols which specifies how to re-order the
> output content).  For ELF layout, sorting atoms by file ordinal then
> atom-ordinal-within-input-file (e.g. address order), will ensure the atoms
> in a section are kept as a cluster.
>
> http://llvm-reviews.chandlerc.com/D3164
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140326/a29cbb4c/attachment.html>