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

On Thu, Jul 30, 2026 at 12:59=E2=80=AFAM H.J. Lu <[email protected]> wrot=
e:
>
> On Thu, Jul 30, 2026 at 3:52=E2=80=AFPM Jan Beulich <[email protected]> w=
rote:
> >
> > On 30.07.2026 09:30, H.J. Lu wrote:
> > > On Thu, Jul 30, 2026 at 3:14=E2=80=AFPM Jan Beulich <[email protected]=
m> wrote:
> > >> On 27.07.2026 10:44, H.J. Lu wrote:
> > >>> Here is the v3 patch.
> > >>
> > >> Thanks, but once again I have to ask: Why did this need rushing in? =
I asked
> > >
> > > We can get real usage today.
> >
> > Well, we could have 10 years ago. No reason to rush.
> >
> > >> before that you please allow at least a week between submission and
> > >> committing. Perhaps except when a change is entirely uncontroversial=
, or
> > >> really urgent to fix e.g. recently introduced breakage (neither of w=
hich is
> > >> the case here).
> > >>
> > >> As to the change itself: We have had support for .slong for a long t=
ime.
> > >> Imo
> > >>
> > >>         .long foo@PLT - .L4
> > >>
> > >> is a bogus construct on 64-bit, and
> > >>
> > >>         .slong foo@PLT - .L4
> > >
> > > We have
> > >
> > > .long foo - .L4
> > >
> > > It is natural to add
> > >
> > > .long foo@PLT - .L4
> >
> > As we add support for a construct previously rejected, imo we'd better
> > demand a well-formed construct there. We can't remove support for bogus
>
> It is no longer bogus after so many years.
>
> > constructs we have always been accepting, so demanding
> >
> >         .slong foo - .L4
> >
> > simply isn't possible.
>
> Not supporting ".long foo@PLT - .L4" while supporting
> ".long foo - .L4" is very strange.  Also llvm-mc supports
> ".long foo@PLT - .L4".

I'd rather we not add `.long foo@plt - .`. R_X86_64_PLT32 is L + A -
P: the PC-relativity is intrinsic to the relocation type, and gas
already emits it from the bare spelling in some cases (e.g. `.globl
foo; .long foo@plt - .`).
There is a real @plt bug worth fixing instead. For a defined local
symbol we drop the specifier and emit an absolute relocation,
silently. `.long foo@plt - .`


The only reason llvm-mc assembles `.long foo@plt - .`  is an
implementation accident from Clang's relative C++ vtables support, and
should be fixed.
I've switched aarch64 to `%pltpcrel(foo)` - there is no risk of
breaking user code - no user assembly at all.

In addition, `.long foo@plt - bar` has unclear semantics: shall we
fold `foo-bar` to a constant if both are in the same section, even not
the current section?

> > >> should be demanded there.
> > >>
> > >> Then: Why do gas/testsuite/gas/i386/reloc{32,64}.s need fiddling wit=
h? .
> > >> should be as suitable to use there as _start / ptr.
> > >
> > > Since
> > >
> > > .long xtrn@plt - .
> > >
> > > works now.
> >
> > In which case it should imo be kept, with the "bad" prefix removed. And
> > the new failure case would be added in addition.
> >
>
> I much prefer to place the working one in a new file.
>
> --
> H.J.