[lld] Handling ELF section groups/.gnu.linkonce sections.

Project Infrastructure LLVM Dev List Archives
1

Hi Nick,

I am trying to implement support for handling section groups in lld.

There are two ways of figuring out section groups with ELF.

a) Sections with SHF_GROUP property
b) .gnu.linkonce sections (the signature identified by the name of the section) – This was the method to coalesce similiar constants.

Section Groups(SHF_GROUP) is the preferred way on ELF but .gnu.linkonce sections is also used.

We would need to support both occurences in ELF files with lld.

Problem

Currently the SymbolTable assumes that an atom is going to be replaced by one another atom, but in the case of a section group, a whole group can be coalesced depending on whether the group with the same signature was previously seen.

Example

For simplicity I am considering two section groups A and B (that have the same signature).

Say A contains atoms A1, A2, A3, and the section group B contains atoms A1", A2", A3"

To complicate things, groups A can contain fewer atoms than group B(currently supported on ELF!) – This happens in environments where the user tried to compile object files and forgot to compile the rest of the object files.

Problem
Its easier to only set the _replaceAtoms[A] = B and the Resolver could just remove B in this case.

Inorder to remove all the atoms in Group B, B and all its layout-after references need to be iterated. The problem is still the _replacedAtoms map that needs to be set before all the atoms in B can be coalesced.

Solution
A way to accomplish this could be to

A) Use the in-group reference along with the layout-after reference. The in-group reference for atoms in the group B are going to contain B as the root of the group.

B) Another way is that we could have a Atom attribute coalescedAway() which would be set for all atoms that we want to remove. This would also need in-group references.

I am ok with either of the methods (A) or (B) but inclined towards (B).

Thanks

Shankar Easwaran

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

2

I was thinking both A & B. That is how I do it with the darwin linker. When a group is parsed, the signature atom has a “group” reference for all the other atoms in the group. When the Resolver replaces one atom with another, it looks to see if the atom has any group references, and if so, marks all those atoms as coalesced away.

-Nick

3

Thanks Nick, I think the coalesce attribute of the atom should not be preserved in the native file right, as this is only a derived attribute after reading the ELF files, isnt it ?

Thanks

Shankar Easwaran

4

There is no coalesced attribute in the Atom model. The Resolver needs to keep track of which atoms got overridden with another atom, so they can be removed from the merged file. That is what I meant by “mark as coalesced away”. In lld, this is done via a replacement map in the SymbolTable object.

The replacement map works well for what it does so far where just individual atoms are replaced with individual atoms by name (e.g. a mergeAsWeak atom is overridden/replaced with another one). But when you are doing group based replacement, there is the issue of what to do if there are references to an atom in a group that is not the signature atom. If the replacement group has a similar atom (by name), it is easy to redirect (in the replacement map) to the new atom. But if the new group does not have such an atom, we need to error. That means the replacement map needs an entry for each atom in a group which has been replaced and replacer atom may need to be some sentinel that there is no replacement, and updateReferences() will need to detect those and error out.

Also, the native and yaml will need a way to encode these groups. If the in-memory model is that the signature atom in a group has a special reference kind to each other atom in the group, those references need to representable in the native and yaml formats.

-Nick