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

[H.J. Lu]

On Thu, Jul 30, 2026 at 3:52 PM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 30.07.2026 09:30, H.J. Lu wrote:
> > On Thu, Jul 30, 2026 at 3:14 PM 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 and
> >> committing. Perhaps except when a change is entirely uncontroversial, 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 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".

> >> should be demanded there.
> >>
> >> Then: Why do gas/testsuite/gas/i386/reloc{32,64}.s need fiddling with? .
> >> 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.