[llvm-commits] Atom alignment

[Nick Kledzik]

On Oct 18, 2012, at 6:32 PM, Shankar Easwaran wrote:
>>> 
>>> So, please, bear with me, I wonder if the ELF model fits neatly ion the atom model.  And, if not, how could the atom model be improved to accommodate it and perhaps other section-based file formats.
>> The mach-o file format has the same problem as ELF, but we've been successfully using the atom model in the darwin linker for 7+ years now.
>> 
>> The trick is to we have an opt-in directive is assembly files (.subsections_via_symbols).  The name is historic, but what it means is that the linker can assume the file follows some rules. The compiler always follows the rules and always uses that directive.   Hand written assembly can (if the author wants) follow the rules and use the directive.
> Its a nice trick, but not sure if all assemblers would be able to follow this rule though.
We don't need all assemblers to follow the rule.   We want to optimize for code coming out of llvm and just be correct for code from elsewhere (other assemblers).   We just need the llvm assembler/MCWriter to opt-in.


>> 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?

> 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?

> 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.

>     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.


> 
> The way to fix these would be to
> 
> 1) Represent sections as Atoms in the lld design ? What do you think ?
> 2) Handle Section Groups by grouping the sections into Atoms by creating AtomSets/AtomCollections
I think the atom model is a better model for linking than the traditional section model.  Once you see how to map section based .o files onto the atom model, linking is much, much simpler.

-Nick