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

On Mon, Aug 3, 2026 at 3:35=E2=80=AFPM Jan Beulich <[email protected]> wrot=
e:
>
> On 03.08.2026 09:22, H.J. Lu wrote:
> > On Mon, Aug 3, 2026 at 2:44=E2=80=AFPM Jan Beulich <[email protected]> =
wrote:
> >>
> >> On 01.08.2026 15:47, Maciej W. Rozycki wrote:
> >>> On Sat, 1 Aug 2026, H.J. Lu wrote:
> >>>
> >>>>>>> Why? .slong was introduced because of a peculiarity of x86-64. If=
 that
> >>>>>>> was straightforward to achieve, it may better not have been expos=
ed to
> >>>>>>> 16- and 32-bit code in the first place. While that ship has saile=
d,
> >>>>>>> suddenly making its use mandatory for certain constructs even out=
side
> >>>>>>> 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 bo=
th 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, t=
he
> >>>>> assembler has to guess, and such guessing can only go wrong. I'm pr=
etty
> >>>>> certain this isn't properly dealt with everywhere, but when adding =
new
> >>>>> functionality we shouldn't extend existing flaws.
> >>>>
> >>>> 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.
> >>>
> >>>  I gather this is about the overflow case, handled differently depend=
ing
> >>> on the signedness or the lack of, of the datum relocated by the stati=
c
> >>> linker or dynamic loader as appropriate.
> >>>
> >>>  Jan, please correct me if I'm wrong since commit d182319b0955 has no
> >>> change description and there's no documentation for `.slong' in the G=
AS
> >>> manual either.  What are the x86 psABI ELF relocation types correspon=
ding
> >>> to `.long' and `.slong' respectively in this context?
> >>
> >> For .long there simply is no correct relocation type to use for PLT (a=
nd,
> >> fwiw, simple PC-relative) expressions. The correct type to use is
> >> R_X86_64_PLT32 (and R_X86_64_PC32 for the simple PC-rel case).
> >>
> >> For the simple PC-rel case we simply cannot require use of .slong, as =
we've
> >> been accepting .long (then guessing that .slong was meant). Else we'd =
very
> >> likely break existing code. Since @PLT was rejected so far when used w=
ith
> >> .long and .slong, doing better here is imo very desirable (if not
> >> imperative).
> >>
> >
> > Because assembler has been correctly generating R_X86_64_PC32 for
> > ".long foo - .L4",
>
> What, again, does "correctly" mean here? We need to retain this incorrect
> behavior, yes, but that doesn't mean we should extend it to other constru=
cts.

Call it "incorrect behavior"  is your opinion.  I certainly disagree.
Given that it
has been used this way from day one, it is the correct behavior for x86-64.


--=20
H.J.