[llvm-commits] [LLD] Patch to tie Atoms in a section together

[Shankar Easwaran]

Hi Nick,

Thanks for pointing things out.

This is a LLD patch for the ELF linker so that Atoms in a section are tied together preventing atoms within a section not garbage collected

>>> This requires some more explanation.  Are you trying to prevent them from ever being removed?  Or they can only be removed is everything is the section is removed?  If the former, the dead-strip setting would do the same.  If the latter, if you are trying to keep the order of the functions, do you want something stronger which says they cannot be reordered too?  The "none" reference just keeps them alive.
>> I am trying to do the latter, they can only be removed only if the section is removed. I couldnt follow why the 'none' reference would not keep the functions together though.
> If someone were to write a Pass which re-ordered functions based.  How would the pass know to not re-order those functions?
>
I will go ahead and create a reference from the current symbol to the 
next symbol too, so that they dont get reordered.
>>> Can we also define some opt-out mechanism for this.  That is when clang produces an ELF file, it won't have the layout restrictions that hand written assembly might have.  So, it would give the linker more flexibility if the clang produced ELF file could be marked to opt-out of these added restrictions.
>> If clang produces the equivalent of -ffunction-sections/-fdata-sections then the linker behaviour will match because atoms within a section will only point to what the section refers to, than referring to each symbol within the section.
> That is a way to opt-in, but rather heavy weight solution.  You are just wrapping every symbol with its own section.   We need an expert on the LLVM ELF Writer to comment on what would make sense to denote compiler generated ELF files (which implicitly can have their sections broken up into Atoms at according to the symbols table entries).
>
With the above, we would be able to compare linker behaviour with lld 
and the system linker and both of them will behave properly.
>>> With regards to the code to do this, it seems like it is O(n^2).    The new method getSymbolIndex() searches the whole symbol table.  The darwin linker (when it needs to do this) puts all the atoms that came from one section into a list, sorts the list by address of each atom in the .o file, then walks the list and adds the references.
>> ReaderELF also has the same functionality but the problem is each relocation entry points to the symbol index of the symbol that appeared in the symbol table.
>>
>> The code is exactly in the same loop as the darwin linker, but the symbol doesnot have the symbol index on where it appears in the symbol table.
> So, this begs the question of why does ELFReference contain a symbolIndex?  Once the parsing is done, all that is needed in each Reference is a pointer to its target.    In the darwin linker, the first phase breaks up the sections into Atoms, and as a side effect builds an array that maps a symbol index to its atom.  Then relocations are parsed.  If a relocation uses a symbol index, the array is consulted to convert that to a Atom pointer.

Ah, I didnt read the code below which sets the targetSymbolIndex to the 
atom, will change the code.

>
>>> * This test uses gcc which means it is not cross platform (i.e. it will fail to run on darwin).  We want all test to be runnable on all platforms.
>> I will change the test to use clang.
> The issue is not gcc vs clang.  The issue is that on Mac or Windows running gcc or clang will not produce an ELF .o file.  To make the test case portable, you need to compile your code to ELF, then use dump-elf (or something) to convert it to a textual representation.  Then in your test case, you read the textual representation and create an ELF .o file in memory which is then parsed into Atoms.
>
> -Nick

I thought clang supports cross compilation, I will change the testcase 
so that it reads an ELF object.

Thanks

Shankar Easwaran


-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation