https://sourceware.org/bugzilla/show_bug.cgi?id=26263
--- Comment #15 from Fangrui Song <maskray at sourceware dot org> --- (In reply to H.J. Lu from comment #7) > [hjl@gnu-cfl-2 pr25551]$ cat x.s > .section .init.text,"ax",@progbits > .global foo > foo: > call printk@PLT > call printk > .text > printk: > ret > [hjl@gnu-cfl-2 pr25551]$ make > as --32 -o x.o x.s > ld -shared -melf_i386 -o x.so x.o > objdump -dw x.so > > x.so: file format elf32-i386 > > > Disassembly of section .text: > > 00001000 <printk>: > 1000: c3 ret > > Disassembly of section .init.text: > > 00001001 <foo>: > 1001: e8 f9 ff ff ff call fff <printk-0x1> > 1006: e8 f5 ff ff ff call 1000 <printk> > [hjl@gnu-cfl-2 pr25551]$ For i386 (implicit addend targets), md_apply_fix sets value = -4 for PLT32, but bfd_install_relocation subsequently subtracts fx_where (the relocation offset within the section) from the instruction bytes. For PC32, this is compensated by the hack at lines 16652-16688 that pre-adds fx_where + fr_address, but BFD_RELOC_386_PLT32 is not in that reloc type list, and the PLT32 case unconditionally overrides value = -4 anyway, discarding any prior compensation. The result is that for call printk@PLT at offset 0 in .init.text, the implicit addend is -5 instead of the correct -4. The 2020 "x86: Change PLT32 reloc against section to PC32" papered over this by avoiding R_386_PLT32 against section symbols entirely, rather than fixing the addend calculation. It also unnecessarily changed R_X86_64_PLT32 against section symbols. to PC32. https://sourceware.org/pipermail/binutils/2026-February/148251.html will properly fix the original bug and revert the workarounds. -- You are receiving this mail because: You are on the CC list for the bug.
