Re: [PATCH v3] x86: Generate PLT32 relocation for ".long foo@PLT - .L4"
"H.J. Lu" <[email protected]> Thu, 30 Jul 2026 15:58:00 +0800
| Newsgroups | gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <CAMe9rOqzs2HKPs0NJpeAgdebrfBajHXQZ6DYNO+noJugcg1ZzQ@mail.gmail.com> |
On Thu, Jul 30, 2026 at 3:52=E2=80=AFPM Jan Beulich <[email protected]> wro= te: > > 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]>= 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 whi= ch is > >> the case here). > >> > >> As to the change itself: We have had support for .slong for a long tim= e. > >> 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. --=20 H.J.