[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relo
From: |
i at maskray dot me |
Subject: |
[Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type |
Date: |
Tue, 19 Sep 2023 07:02:59 +0000 |
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.
- [Bug ld/30844] New: ld riscv: --emit-relocs does not retain the original relocation type, i at maskray dot me, 2023/09/12
- [Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type, i at maskray dot me, 2023/09/12
- [Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type, i at maskray dot me, 2023/09/12
- [Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type, palmer at gcc dot gnu.org, 2023/09/12
- [Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type, i at maskray dot me, 2023/09/13
- [Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type, palmer at gcc dot gnu.org, 2023/09/13
- [Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type, nelsonc1225 at sourceware dot org, 2023/09/13
- [Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type, amodra at gmail dot com, 2023/09/14
- [Bug ld/30844] ld riscv: --emit-relocs does not retain the original relocation type,
i at maskray dot me <=