R_LARCH_TLS_{LD,GD,DESC}_PCREL20_S2

[rui314]

Is it really the case that compiler/assembler emits R_LARCH_TLS_{LD,GD,DESC}_PCREL20_S2 relocations? It looks like these are GNU ld's internal relocations and never occur in real-world object files. If that's the case, these relocations should be removed from the psABI. We've removed GNU ld's internal relocations from RISC-V's psABI, too.

[SixWeining]

Both gnu-as and llvm-as can emit these relocations:

• https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/testsuite/gas/loongarch/relocs_64.s;h=1d1548f5b6832f0a8b89dd6b73801a1f70ba2223;hb=HEAD#l106
• [LoongArch][MC] Support %[ld_/gd_/desc_]pcrel_20 llvm/llvm-project#100104

What do you mean that these are GNU ld's internal relocations?

cc @chenglulu326 @scylaac @wangleiat

[rui314]

My guessing is that they are implemented to GNU/LLVM assembler just because they are in this psABI spec, but they don't seem to be necessary in the first place (i.e. I suspect this is a spec bug). What are the real use cases of these relocations?

For RISC-V, GNU ld defines bunch of implementation-defined relocations for relaxations, and they were accidentally registered to the psABI spec. We've removed them; see riscv-non-isa/riscv-elf-psabi-doc@9f15402 for example.

[rui314]

I'm also pretty sure that you guys want to remove R_LARCH_GNU_VTINHERIT and R_LARCH_GNU_VTENTRY. See riscv-non-isa/riscv-elf-psabi-doc@97690f6.

[MQ-mengqing]

My guessing is that they are implemented to GNU/LLVM assembler just because they are in this psABI spec, but they don't seem to be necessary in the first place (i.e. I suspect this is a spec bug). What are the real use cases of these relocations?

There may be a tiny model on LoongArch, (in the future ?). https://gcc.gnu.org/onlinedocs/gcc/LoongArch-Options.html#index-mcmodel_003d-1

[rui314]

Since LoongArch defines section-shrinking linker relaxations, there's no use for these _S2 variant of relocations over their corresponding HI/LO pair of relocations, is there? It seems ratifying the _S2 variant only causes issues in the future; you guys don't really want any compiler to use these relocations.

After all, it's your psABI, so that's just my two cents. I just wanted you guys know that we've fixed the same problem for RISC-V.

[SixWeining]

I think bolt needs these relocation types (--emit-relocs).

[xen0n]

I think it's primarily a decision over whether we want to be able to express (1) any possible relocation operation permitted by the ISA capability, or (2) just those relevant to the typical compile-link workflow. In the latter case, all relocations are emitted by the compiler in the longest form possible, to be shrinked by the linker's relaxation pass, later and once. But if we want to still preserve the relocations in the linker output we'd probably still want to have additional reloc types around.

Is my understanding correct?