https://sourceware.org/bugzilla/show_bug.cgi?id=32196
--- Comment #7 from Fangrui Song <maskray at sourceware dot org> ---
(In reply to Fangrui Song from comment #6)
> We should revisit the resolution to PR25551 and PR32196.
>
> I raised PR25551 due to an unneeded .symtab entry .Lprintk$local .
> The resolution changed R_X86_64_PLT32 to R_X86_64_PC32, which is less
> desirable, and required an amendment for this issue.
>
> PLT32 is a branch relocation type, which means the symbol address is
> insignificant (similar to R_AARCH64_CALL26 / R_PPC64_REL24).
> In a modified large code model, we could instruct the linker to create a
> range extension thunk if the target symbol is out of reach of +-2GiB.
>
> .section .init.text,"ax",@progbits
> call .Lprintk$local
> # -- End function
> .text
> .globl printk # -- Begin function printk
> .type printk,@function
> printk: # @printk
> .Lprintk$local:
> ret
>
> Using PC32 means the symbol address is significant, and we cannot safely
> redirect the relocation (without disassembling the instruction) to a thunk.
>
> For this assembly sequence, LLVM integrated assembler generates the desired
> R_X86_64_PLT32 relocation referencing .text - 4, which allows range
> extension thunks.
We can simply 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").
https://sourceware.org/pipermail/binutils/2026-February/148154.html
The patch does not change the behavior of
# 64-bit
mov $plt32@plt, %rax # PLT32, plt32+0
mov $plt32@plt - ., %rax # PLT32, plt32-4
--
You are receiving this mail because:
You are on the CC list for the bug.
