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

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added inline comments.


================
Comment at: ELF/Relocations.cpp:1005
+  // 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
----------------
sfertile wrote:
> MaskRay wrote:
> > 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.
> 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.  
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


Repository:
  rLLD LLVM Linker

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D57245/new/

https://reviews.llvm.org/D57245