Re: [PATCH v2] x86: Generate PLT32 relocation for ".long foo@PLT - .L4"

"H.J. Lu" <[email protected]> Mon, 27 Jul 2026 15:58:18 +0800
Newsgroups gmane.comp.gnu.binutils
Message-ID <CAMe9rOoM755+J=P58kd0j-TDSWOb1mf2qUc_SjsYGZNg2PxyBQ@mail.gmail.com>
On Mon, Jul 27, 2026 at 3:46 PM Jan Beulich <[email protected]> wrote:
>
> On 27.07.2026 05:47, H.J. Lu wrote:
> > On Sat, Jul 25, 2026 at 10:35 AM H.J. Lu <[email protected]> wrote:
> >>
> >> Add BFD_RELOC_X86_64_PLT32 and use it to generate R_X86_64_PLT32 for
> >> directives like ".long foo@PLT - .L4" so that PLT entries are used to
> >> resolve the PC32 relocation against function symbols for such directives.
> >>
> >> bfd/
> >>
> >> PR gas/34423
> >> * elf64-x86-64.c (x86_64_reloc_map): Add BFD_RELOC_X86_64_PLT32.
> >> * reloc.c (bfd_reloc_code_real): Add BFD_RELOC_X86_64_PLT32.
> >> * bfd-in2.h: Regenerated.
> >> * libbfd.h: Likewise.
> >>
> >> gas/
> >>
> >> PR gas/34423
> >> * config/tc-i386.c (x86_cons): Return BFD_RELOC_X86_64_PLT32 for
> >> directives like ".long foo@PLT - .L4".
> >> (tc_gen_reloc): Generate R_X86_64_PLT32 for BFD_RELOC_X86_64_PLT32
> >> with addend computed like R_X86_64_PC32.
> >> * testsuite/gas/i386/reloc64.l: Updated.
> >> * testsuite/gas/i386/reloc64.s: Replace ".long xtrn@plt - ." with
> >> ".long xtrn@plt - _start".
> >> * testsuite/gas/i386/ilp32/reloc64.l: Updated.
> >> * testsuite/gas/i386/ilp32/reloc64.s: Replace ".long xtrn@plt - ."
> >> with ".long xtrn@plt - ptr".
> >> * testsuite/gas/i386/x86-64-jump-table.d: New file.
> >> * testsuite/gas/i386/x86-64-jump-table.d: Likewise.
> >> * testsuite/gas/i386/x86-64-jump-table.s: Likewise.
> >> * testsuite/gas/i386/x86-64.exp: Run x86-64-jump-table.
> >> * testsuite/gas/i386/ilp32/x86-64-jump-table.d: New file.
> >>
> >> ld/
> >>
> >> PR gas/34423
> >> * testsuite/ld-x86-64/pr34423.c: New file.
> >> * testsuite/ld-x86-64/x86-64-jump-table.s: Likewise.
> >> * testsuite/ld-x86-64/x86-64.exp: Run gas/34423 tests.
> >
> > Add i386 support like LLVM assembler in the v2 patch.
>
> Why would S_IS_LOCAL() be the criteria? There isn't anything wrong with a

I will remove it.

> global, at the very least a hidden/protected one, is there? Instead don't
> you want to verify that the subtrahend is in the current section (which
> of course we may not know until after having parsed all input)?

It will be reverified later :

[hjl@gnu-tgl-3 pic-1]$ cat bar.s
        .section .rodata
        .p2align 2
.L4:
        .long foo1@PLT - bar
[hjl@gnu-tgl-3 pic-1]$ ./as  -o bar.o bar.s
bar.s: Assembler messages:
bar.s:4: Error: can't resolve foo1 - bar
[hjl@gnu-tgl-3 pic-1]$

> Surprising code like
>
> +      if (fixp->fx_r_type == BFD_RELOC_X86_64_PC32_TO_PLT32)
> +       code = BFD_RELOC_X86_64_PC32_TO_PLT32;
> +      else if (fixp->fx_r_type == BFD_RELOC_386_PC32_TO_PLT32)
> +       code = BFD_RELOC_386_PLT32;
>
> imo wants at least a brief comment as to the different behavior for i386
> vs x86-64.
>

I will add some comments.

-- 
H.J.