https://sourceware.org/bugzilla/show_bug.cgi?id=30844
--- Comment #6 from Fangrui Song <i at maskray dot me> --- (In reply to Alan Modra from comment #5) > (In reply to Fangrui Song from comment #0) > > For GNU ld's AArch64/PPC64/x86-64 ports, the --emit-relocs code retains the > > original relocation type even if a linker optimization is applied. > > No, ppc64 adjusts relocations to match the emitted code. See for example > R_PPC64_GOT16_LO_DS handling in ppc64_elf_relocate_section, adjusted to > R_PPC64_TOC16_LO when a got indirect code sequence can be edited to got > pointer relative. > > > This is partly to communicate more information to the analysis tool > > This is exactly why relocations for ppc64 (and ppc32) were edited. IBM's > FDPR post-link optimisation tool used them. ppc64 even emits relocs for > linker generated stub code. > > The fact that other targets emit the original relocations is not a good > argument for saying that riscv should do so. Most maintainers of other > targets simply didn't see a need to correct the relocs when editing code. Thanks for the reply! I did not know. I have now made some notes on https://maskray.me/blog/2023-02-26-linker-notes-on-power-isa#emit-relocs For example, a TOC-indirect to TOC-relative optimization uses a pair of relocations `R_PPC64_TOC16_HA(.toc)+R_PPC64_TOC16_LO_DS(.toc)`. After optimization, they will become `R_PPC64_TOC16_HA(sym)+R_PPC64_TOC16_LO(sym)`. The `R_PPC64_TOC16_HA` relocation is present even if the first instruction is converted to a NOP. A general-dynamic TLS model code sequence may use relocations `R_PPC64_GOT_TLSGD16_HA+R_PPC64_GOT_TLSGD16_LO+R_PPC64_TLSGD+R_PPC64_REL24`. After optimization, they will become: * `R_PPC64_NONE+R_PPC64_TPREL16_HA+R_PPC64_TPREL16_LO+R_PPC64_NONE` after general-dynamic to local-exec TLS optimization. * `R_PPC64_GOT_TPREL16_HA+R_PPC64_GOT_TPREL16_LO_DS+R_PPC64_NONE+R_PPC64_NONE` after general-dynamic to initial-exec TLS optimization. So it seems that ppc performed conversion can all be described by existing relocation types, which is nice. However, I do not know whether the property will hold for all current and future RISC-V relaxation schemes. When investigating relocation overflow pressure for x86-64 small code model, I have found that preserving the original relocation type gives me more information: I can tell how many R_X86_64_PC32/R_X86_64_GOTPCRELX/R_X86_64_REX_GOTPCRELX are problematic. If they are converted to R_X86_64_PC32/R_X86_64_32, I'd lose some information. Perhaps whether the --emit-relocs uses the original relocation type or the transformed relocation type , does not matter for the majority of use cases. E.g. Linux kernel's objtool, seems to perform a sanity check on relocations. It just needs to know the categories of relocations, e.g. absolute/PC-relative, not the exact type. -- You are receiving this mail because: You are on the CC list for the bug.