[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type

[i at maskray dot me]

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.