[PPC64] Sort .toc sections accessed with small code model relocs close to the .got part 2

[sfertile]

Summary

Follow on patch which addresses the other small code model relocation types. For lld we should ignore the small code model relocations that represent offsets to entries in the .got for sorting purpose. Since these relocations don't access the .toc sections they should have no bearing on how we sort the .toc sections, and since we don't sort got entries (they are allocated on demand in order) we don't need to track which objects contain these relocation types.

[ruiu]

ELF/Arch/PPC64.cpp

101–103

Could you update the comment a bit so that it gives the big picture about what this function does? Looks like this comment is slightly too detailed and might not be understood if you already know what this is for.

[sfertile]

Updated /moved a few comments.

[sfertile]

ELF/Arch/PPC64.cpp

101–103

The previous comment was a bit out of place here. It had a lot of PPC specific details so I thought I should bury it in the PPC target. I've removed the specific relocations and moved the comment into scanRelocs. I think it makes sense there now as it explains why we only need to flag certain small code model relocations for the sorting (as opposed to what bfd and gold do).

[MaskRay]

ELF/Relocations.cpp

1005

The description of GOT is verbose.. and I don't get why it is not necessary for small code model sorting.

(Glad to know that we don't need a ton of GOT relocations used in binuitls-gdb: R_PPC64_GOT_TLSLD16 R_PPC64_GOT_TPREL16_DS R_PPC64_GOT16 ...)

Than change LG.

[sfertile]

ELF/Relocations.cpp

1005

Ok, let me try to explain it in a different way. let me know if this is better:

We can separate the small code model relocations into 2 categories:
1) Those that access the compiler generated .toc  sections.
2) Those that access the linker allocated got entries.
lld allocates got entries to symbols on demand. Since we don't try to sort the got entries in any way we don't have to track which objects have got-based small code model relocs. The .toc sections get placed after the end of the linker allocated .got section and we do sort those so sections addressed with small code model relocations come first.

I don't know what ld.bfd and gold do, but from the snippet you posted on the previous review I would guess they do sort the .got entries. I think llds current behavior is reasonable though. Since the compilers emit .toc entries for most/all of the indirection the size of the actual linker allocated portion of the .got tend to be quite small. The majority of the .gots size comes from the merged in .toc sections which we do sort and layout to maximize addressability. Having a .got thats large enough to overflow a small code model relocation on its own is pretty unlikely.

If any of the compilers switched to use the got-indirections described in the ABI rather then using the .toc section for indirections then I think we should reconsider sorting the .got entries based on small code model addressability.

[ruiu]

LGTM

[MaskRay]

ELF/Relocations.cpp

1005

Thanks for the explanation. I've read some documentation and agree that got-indirect relocation types have a less chance to get overflow. Sorting GOT entries does not change the computed values of R_PPC64_TOC16 R_PPC64_TOC16_DS. Handling just R_PPC64_TOC16 and R_PPC64_TOC16_DS should provide a good coverage.

// libgcc.a
__fixunssfti:

0:       00 00 4c 3c     addis 2, 12, 0
         0000000000000000:  R_PPC64_REL16_HA     .TOC.
4:       00 00 42 38     addi 2, 2, 0
         0000000000000004:  R_PPC64_REL16_LO     .TOC.+4
8:       00 00 c2 e8     ld 6, 0(2)
         0000000000000008:  R_PPC64_TOC16_DS     .toc       ######### this can go overflow

ELF/Arch/PPC64.cpp

unsigned elf::getPPC64GlobalEntryToLocalEntryOffset(uint8_t StOther) {
   // log-base-2(offset).
   if (GepToLep < 7)
     return 1 << GepToLep;
 
   error("reserved value of 7 in the 3 most-significant-bits of st_other");
   return 0;
 }
 
-bool elf::isPPC64SmallCodeModelReloc(RelType Type) {
-  // List is not yet complete, at the very least the got based tls related
-  // relocations need to be added, and we need to determine how the section
-  // sorting interacts with the thread pointer and dynamic thread pointer
-  // relative tls relocations.
-  return Type == R_PPC64_GOT16 || Type == R_PPC64_TOC16 ||
-         Type == R_PPC64_TOC16_DS;
+bool elf::isPPC64SmallCodeModelTocReloc(RelType Type) {
+  // The only small code model relocations that access the .toc section.
+  return Type == R_PPC64_TOC16 || Type == R_PPC64_TOC16_DS;
 }
 
 namespace {
 class PPC64 final : public TargetInfo {
 public:
   PPC64();
   uint32_t calcEFlags() const override;
   RelExpr getRelExpr(RelType Type, const Symbol &S,

ELF/InputFiles.h

public:
 
   std::string getSrcMsg(const Symbol &Sym, InputSectionBase &Sec,
                         uint64_t Offset);
 
   // True if this is an argument for --just-symbols. Usually false.
   bool JustSymbols = false;
 
   // On PPC64 we need to keep track of which files contain small code model
-  // relocations. To minimize the chance of a relocation overflow files that do
-  // contain small code model relocations should have their .toc sections sorted
-  // closer to the .got section than files that do not contain any small code
-  // model relocations. Thats because the toc-pointer is defined to point at
-  // .got + 0x8000 and the instructions used with small code model relocations
-  // support immediates in the range [-0x8000, 0x7FFC], making the addressable
-  // range relative to the toc pointer [.got, .got + 0xFFFC].
-  bool PPC64SmallCodeModelRelocs = false;
+  // relocations that access the .toc section. To minimize the chance of a
+  // relocation overflow, files that do contain said relocations should have
+  // their .toc sections sorted closer to the .got section than files that do
+  // not contain any small code model relocations. Thats because the toc-pointer
+  // is defined to point at .got + 0x8000 and the instructions used with small
+  // code model relocations support immediates in the range [-0x8000, 0x7FFC],
+  // making the addressable range relative to the toc pointer
+  // [.got, .got + 0xFFFC].
+  bool PPC64SmallCodeModelTocRelocs = false;
 
   // GroupId is used for --warn-backrefs which is an optional error
   // checking feature. All files within the same --{start,end}-group or
   // --{start,end}-lib get the same group ID. Otherwise, each file gets a new
   // group ID. For more info, see checkDependency() in SymbolTable.cpp.
   uint32_t GroupId;
   static bool IsInGroup;
   static uint32_t NextGroupId;

ELF/Relocations.cpp

static void scanReloc(InputSectionBase &Sec, OffsetGetter &GetOffset, RelTy *&I,
 
   const uint8_t *RelocatedAddr = Sec.data().begin() + Rel.r_offset;
   RelExpr Expr = Target->getRelExpr(Type, Sym, RelocatedAddr);
 
   // Ignore "hint" relocations because they are only markers for relaxation.
   if (isRelExprOneOf<R_HINT, R_NONE>(Expr))
     return;
 
-  if (Config->EMachine == EM_PPC64 && isPPC64SmallCodeModelReloc(Type))
-    Sec.File->PPC64SmallCodeModelRelocs = true;
+  // In regards to the .toc section sorting (to avoid small code model
+  // relocation overflows) we need only to identify those small code model
+  // relocations that will access the .toc section. The got based small code
+  // model relocations inform the linker to create a got entry (or entries) and
+  // fill in the instructions with the offset from the toc pointer to said got
+  // entry. Since they access the .got instead of the .toc, and we don't try to
+  // sort .got entries based on code model, we can ignore the got based
+  // relocations.
+  if (Config->EMachine == EM_PPC64 && isPPC64SmallCodeModelTocReloc(Type))
+    Sec.File->PPC64SmallCodeModelTocRelocs = true;
 
   // Strenghten or relax relocations.
   //
   // GNU ifunc symbols must be accessed via PLT because their addresses
   // are determined by runtime.
   //
   // On the other hand, if we know that a PLT entry will be resolved within
   // the same ELF module, we can skip PLT access and directly jump to the

ELF/Target.h

 // a global entry point (GEP) which typically is used to intiailzie the TOC
 // pointer in general purpose register 2.  The second is a local entry
 // point (LEP) which bypasses the TOC pointer initialization code. The
 // offset between GEP and LEP is encoded in a function's st_other flags.
 // This function will return the offset (in bytes) from the global entry-point
 // to the local entry-point.
 unsigned getPPC64GlobalEntryToLocalEntryOffset(uint8_t StOther);
 
-bool isPPC64SmallCodeModelReloc(RelType Type);
+// Returns true if a relocation is a small code model relocation that accesses
+// the .toc section.
+bool isPPC64SmallCodeModelTocReloc(RelType Type);
 
 uint64_t getPPC64TocBase();
 uint64_t getAArch64Page(uint64_t Expr);
 
 extern TargetInfo *Target;
 TargetInfo *getTarget();
 
 template <class ELFT> bool isMipsPIC(const Defined *Sym);

ELF/Writer.cpp

static void sortSection(OutputSection *Sec,
   // sections having smaller relocation offsets are at beginning of .toc
   if (Config->EMachine == EM_PPC64 && Name == ".toc") {
     if (Script->HasSectionsCommand)
       return;
     assert(Sec->SectionCommands.size() == 1);
     auto *ISD = cast<InputSectionDescription>(Sec->SectionCommands[0]);
     std::stable_sort(ISD->Sections.begin(), ISD->Sections.end(),
                      [](const InputSection *A, const InputSection *B) -> bool {
-                       return A->File->PPC64SmallCodeModelRelocs &&
-                              !B->File->PPC64SmallCodeModelRelocs;
+                       return A->File->PPC64SmallCodeModelTocRelocs &&
+                              !B->File->PPC64SmallCodeModelTocRelocs;
                      });
     return;
   }
 
   // Sort input sections by priority using the list provided
   // by --symbol-ordering-file.
   if (!Order.empty())
     for (BaseCommand *B : Sec->SectionCommands)