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.
