[LLVMdev] [llvm-commits] Atom alignment

[Shankar Easwaran]

Hi Nick,

Thanks for the reply.

On 10/19/2012 5:18 PM, Nick Kledzik wrote:
>
>  From the linker's perspective, if the directive was not used, it has to be more conservative it what it can do with the file.  In particular it adds a "follow-on" reference from each atom in a section to the next one.  The follow-on atoms constrain the layout engine that particular atoms must layout right after another.  So, if an order file is used to move one atom there may be a whole train of atoms that move with it
>> When each section have different alignment requirements, it would be really hard to fix the alignment, when atoms get removed due to Garbage collection right ?
>>
>> The additional problems that
>>
>> 1) The Atom model forgets the relation between sections after parsing the Input file
> What do you mean "relation between sections"?  What information is lost?
The relation between sections on which section has to precede which 
section is lost, because the output order is written by the order of 
atoms that we processed.

For example, if we have two object files 1.o and 2.o, each containing 
.text/.data sections in them and the .data section in the second file 
(2.o) specifies a particular link order by using (SHF_LINK_ORDER), the 
ordering from 2.o takes priority from the other ones and we seem to have 
lost that information when we read the Section right ?

Also we may have differing alignment requirements for each section, but 
we have alignment information at the Atom level.
>
>> 2) We dont have a way to layout the atoms to fix their offsets/order after reading the files like traditional linkers which run with ELF files
> You can write an lld Pass to re-order atoms. Each atom's Alignment info is its constraint on how it can be laid out.    What do you think is missing?

I think we should have a layout pass which is applicable to all linkers.

1) Ordering/Grouping atoms when we write to the output file will become 
easier
2) When we add linker script support, it clearly maps into this usecase
>> 3) Certain things w.r.t the ELF file is not completely represented by Atoms
>>      a) Merging constants in the sections have SHF_MERGE/SHF_STRINGS flag set
> This idea for SHF_MERGE/SHF_STRINGS sections is that the content is broken upon into atoms based on the sh_entsize value.  The atoms have a merge type of mergeByConent (which seems to be currently missing from DefinedAtom.h).  The core linking  part of lld knows to coalesce atoms that have the same size and content if their merge type is mergeByConent.
I will go ahead and add the type when I have support for this.
>
>>      b) Handling section groups (SHT_GROUP) for C++ comdat resolution
> The group comdat model is that there is a group of symbols one of which is the "signature" symbol.  If the signature symbol is coalesced away, all the the symbols in the group are thrown away.  If the signature symbols remains, then all symbols remain.  In the atom model, the signature atom has a "group subordinate" reference to each other atom in the group.  If the signature atom is coalesced away, then all the subordinate atoms are also coalesced away.

I think you meant group of sections above.

How do you represent a group of symbols/sections as a set in the current 
model ?

Thanks

Shankar Easwaran
Qualcomm Innovation Center.