[PATCH] x86: keep PLT32 relocation for local symbols instead of converting to PC32

[Jan Beulich]

On 09.02.2026 00:26, Fangrui Song wrote:
> Revert the PLT32-to-PC32 conversions introduced by commits 2585b7a5ce58
> ("x86: Change PLT32 reloc against section to PC32") and ad2ce1e6457c
> ("x86: Turn PLT32 to PC32 only for PC-relative relocations").
> 
> PLT32 is a branch relocation type where the symbol address is
> insignificant (similar to R_AARCH64_CALL26 and R_PPC64_REL24).

I fear I don't understand this wording: The (ultimate) symbol address is
very much relevant, or else the wrong contents will be put in the PLT?

> Converting it to PC32 makes the symbol address significant, which
> prevents the linker from making certain transforms (e.g.
> a relocation-based identical code folding feature might
> disallow folding a section if it defines symbols with significant
> addresses.)
> 
> With this change, PLT32 relocations against local symbols (including .L
> local labels) are adjusted to reference the section symbol (via
> adjust_reloc_syms), matching the longstanding behavior of LLVM
> integrated assembler.  PLT32 relocations referencing section symbols are
> well supported by ld,
> 
> 	PR gas/25551

It was you who reported that bug. Are you now saying that report was wrong?
This really needs discussing here, imo (even if it would have been someone
else who made that original report).

In this context I'd like to point out that there may be more issues here.
Using PLT32 without the programmer having said so is questionable.
Strictly speaking (without any later optimization, i.e. without making
assumptions on eventual consumers) this means a PLT entry needs allocating.
Especially for local (and even hidden or protected) symbols this doesn't
look right. At the same time the programmer having used @plt should result
in a PLT32 relocation, no matter what kind the referenced symbol might be.

The hybrid approach presently used really should have used another reloc
type, I think.

Jan