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

On Thu, Jul 30, 2026 at 4:24=E2=80=AFPM Fangrui Song <[email protected]> wrote:
>
> On Thu, Jul 30, 2026 at 12:59=E2=80=AFAM H.J. Lu <[email protected]> wr=
ote:
> >
> > On Thu, Jul 30, 2026 at 3:52=E2=80=AFPM Jan Beulich <[email protected]>=
 wrote:
> > >
> > > On 30.07.2026 09:30, H.J. Lu wrote:
> > > > On Thu, Jul 30, 2026 at 3:14=E2=80=AFPM Jan Beulich <jbeulich@suse.=
com> 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 an=
d
> > > >> committing. Perhaps except when a change is entirely uncontroversi=
al, or
> > > >> really urgent to fix e.g. recently introduced breakage (neither of=
 which is
> > > >> the case here).
> > > >>
> > > >> As to the change itself: We have had support for .slong for a long=
 time.
> > > >> 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 bette=
r
> > > demand a well-formed construct there. We can't remove support for bog=
us
> >
> > 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 - .`

OK. I will change it to ".slong foo@PLT - .L4".

>
> 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 w=
ith? .
> > > >> 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. A=
nd
> > > the new failure case would be added in addition.
> > >
> >
> > I much prefer to place the working one in a new file.
> >
> > --
> > H.J.



--=20
H.J.