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

On Mon, Aug 3, 2026 at 5:01=E2=80=AFPM Jan Beulich <[email protected]> wrot=
e:
>
> On 03.08.2026 10:52, H.J. Lu wrote:
> > On Mon, Aug 3, 2026 at 3:35=E2=80=AFPM Jan Beulich <[email protected]> =
wrote:
> >>
> >> 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 exp=
osed to
> >>>>>>>>> 16- and 32-bit code in the first place. While that ship has sai=
led,
> >>>>>>>>> suddenly making its use mandatory for certain constructs even o=
utside
> >>>>>>>>> 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. .lon=
g should
> >>>>>>> only ever use zero-extending ones; .slong was added such that wan=
t 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 addin=
g 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 depe=
nding
> >>>>> on the signedness or the lack of, of the datum relocated by the sta=
tic
> >>>>> 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=
 GAS
> >>>>> manual either.  What are the x86 psABI ELF relocation types corresp=
onding
> >>>>> to `.long' and `.slong' respectively in this context?
> >>>>
> >>>> For .long there simply is no correct relocation type to use for PLT =
(and,
> >>>> 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, a=
s 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=
 with
> >>>> .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 incorr=
ect
> >> behavior, yes, but that doesn't mean we should extend it to other cons=
tructs.
> >
> > 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.
>
> How can it be correct if it would break if a suitable relocation was intr=
oduced?
> Just because it has been this way from the start of x86-64 doesn't mean i=
t was
> right. There are many things which needed correction later one One of the=
m being
> the original lack of .slong.

That is purely your opinion.   I don't think correction is needed on this.

--=20
H.J.