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

"H.J. Lu" <[email protected]> Sat, 1 Aug 2026 05:03:58 +0800
Newsgroups gmane.comp.gnu.binutils
Message-ID <CAMe9rOqDG=mcuiiNdcYSbA0PEXeUJMQ+hrxPuJ=KQV5=4Q3bTQ@mail.gmail.com>
On Fri, Jul 31, 2026 at 6:55=E2=80=AFPM Jan Beulich <[email protected]> wro=
te:
>
> On 31.07.2026 12:47, H.J. Lu wrote:
> > On Fri, Jul 31, 2026 at 5:03=E2=80=AFPM Jan Beulich <[email protected]>=
 wrote:
> >>
> >> On 31.07.2026 10:55, H.J. Lu wrote:
> >>> On Fri, Jul 31, 2026 at 4:26=E2=80=AFPM Jan Beulich <[email protected]=
m> wrote:
> >>>>
> >>>> On 31.07.2026 01:09, H.J. Lu wrote:
> >>>>> Disallow ".long foo@PLT - .L4" and only allow ".slong foo@PLT - .L4=
" for
> >>>>> PLT32 relocation.
> >>>>
> >>>> Why would you enforce this also for 32-bit, where the difference bet=
ween
> >>>> .slong and .long is entirely benign? The existing cons_sign should b=
e
> >>>> sufficient to achieve what's needed for 64-bit code.
> >>>>
> >>>
> >>> I compared ".long foo@PLT - .L4":
> >>>
> >>>         .section .rodata
> >>>         .p2align 2
> >>> .L4:
> >>>         .long foo1@PLT - .L4
> >>>         .long foo2@PLT - .L4
> >>>         .long foo3@PLT - .L4
> >>>         .long foo4@PLT - .L4
> >>>         .long foo1@PLT - .L5
> >>>         .long foo2@PLT - .L5
> >>>         .long foo3@PLT - .L5
> >>>         .long foo4@PLT - .L5
> >>> .L5:
> >>>
> >>> vs ".slong foo@PLT - .L4":
> >>>         .section .rodata
> >>>         .p2align 2
> >>> .L4:
> >>>         .slong foo1@PLT - .L4
> >>>         .slong foo2@PLT - .L4
> >>>         .slong foo3@PLT - .L4
> >>>         .slong foo4@PLT - .L4
> >>>         .slong foo1@PLT - .L5
> >>>         .slong foo2@PLT - .L5
> >>>         .slong foo3@PLT - .L5
> >>>         .slong foo4@PLT - .L5
> >>> .L5:
> >>>
> >>> in 64-bit.   The output object files are identical.  If we don't allo=
w
> >>> ".long foo@PLT - .L4" in 64-bit, we shouldn't allow it in 32-bit.
> >>
> >> Why? .slong was introduced because of a peculiarity of x86-64. If that
> >> was straightforward to achieve, it may better not have been exposed to
> >> 16- and 32-bit code in the first place. While that ship has sailed,
> >> suddenly making its use mandatory for certain constructs even outside
> >> of 64-bit code feels outright wrong.
> >
> > What is wrong with using " .long foo4@PLT - .L4" in 64-bit?
> > The possible reason could be wrong code.  You don't like it
> > doesn't count.
>
> It's not a matter of liking it (or not). The distinction between both is
> what relocation is (supposed to be) used when one is needed. .long should
> only ever use zero-extending ones; .slong was added such that want for a
> sign-extending one can be expressed. Without distinct directives, the
> assembler has to guess, and such guessing can only go wrong. I'm pretty
> certain this isn't properly dealt with everywhere, but when adding new
> functionality we shouldn't extend existing flaws.
>
> Jan

Given that there are no issues with ".long foo - .L4",
".long foo1@PLT - .L4" should have no issues at all.
If you believe that it isn't true, please show me a case.

--=20
H.J.