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

[Jan Beulich]

On 09.02.2026 09:46, Fangrui Song wrote:
> On Mon, Feb 9, 2026 at 12:23 AM Jan Beulich <jbeulich@suse.com> wrote:
>> 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?
> 
> The x86-64 PLT32 relocation type is a branch relocation type, which
> can be used to make a function call but not by taking the address
> (pointer escape).
> The name is a misnomer (therefore on arm/aarch64/ppc they are not
> called "R_*_PLT*") - if the target symbol is non-preemptible, the
> linker resolves the relocation as a direct PC-relative one.

Taking Arm64 as example, can you even compare with that? I couldn't spot
any relocation using L in the "Operation" column.

> On RISC architectures, branch instructions often have a limited
> immediate range. For similar branch relocation types, linkers are
> permitted to generate range extension thunks (or "stubs" "veneers") to
> bridge the gap if the target is too far from the call site.
> There are proposals to add range-extension thunks for x86-64.

Yes, I've seen that. But we don't want to break other things while
introducing such an extension.

>>> 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).
> 
> The patch I submitted for gas/25551 is correct.
> 
> However, the follow-up 2585b7a5ce58
> ("x86: Change PLT32 reloc against section to PC32") changed PLT32
> against a section symbol to PC32.
> This stripped the "address is insignificant" information - therefore undesired.

Then what about PR gas/26263, which triggered this patch's creation?

> A PC32 branch relocation is indistinguishable from an address-taken
> operation without disassembling the instruction.
> If the address is taken, the linker has to be conservative - and
> disable features such as Identical Code Folding and range extension
> thunks.

Yes, we're certainly in agreement here.

>> 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.
> 
> With this patch yeah `@plt` should always lead to a PLT32 relocation.

Yet the opposite also wants to be true - without @plt there shouldn't be use
of this reloc type.

Jan