Re: [PATCH] x86: Disallow ".long foo@PLT - .L4" for PLT32 relocation
Jan Beulich <[email protected]> Fri, 31 Jul 2026 12:55:54 +0200
| Newsgroups | gmane.comp.gnu.binutils |
|---|---|
| Message-ID | <[email protected]> |
On 31.07.2026 12:47, H.J. Lu wrote: > On Fri, Jul 31, 2026 at 5:03 PM Jan Beulich <[email protected]> wrote: >> >> On 31.07.2026 10:55, H.J. Lu wrote: >>> On Fri, Jul 31, 2026 at 4:26 PM Jan Beulich <[email protected]> wrote: >>>> >>>> On 31.07.2026 01:09, H.J. Lu wrote: >>>>> Disallow ".long foo@PLT - .L4" and only allow ".slong foo@PLT - .L4" for >>>>> PLT32 relocation. >>>> >>>> Why would you enforce this also for 32-bit, where the difference between >>>> .slong and .long is entirely benign? The existing cons_sign should be >>>> sufficient to achieve what's needed for 64-bit code. >>>> >>> >>> I compared ".long foo@PLT - .L4": >>> >>> .section .rodata >>> .p2align 2 >>> .L4: >>> .long foo1@PLT - .L4 >>> .long foo2@PLT - .L4 >>> .long foo3@PLT - .L4 >>> .long foo4@PLT - .L4 >>> .long foo1@PLT - .L5 >>> .long foo2@PLT - .L5 >>> .long foo3@PLT - .L5 >>> .long foo4@PLT - .L5 >>> .L5: >>> >>> vs ".slong foo@PLT - .L4": >>> .section .rodata >>> .p2align 2 >>> .L4: >>> .slong foo1@PLT - .L4 >>> .slong foo2@PLT - .L4 >>> .slong foo3@PLT - .L4 >>> .slong foo4@PLT - .L4 >>> .slong foo1@PLT - .L5 >>> .slong foo2@PLT - .L5 >>> .slong foo3@PLT - .L5 >>> .slong foo4@PLT - .L5 >>> .L5: >>> >>> in 64-bit. The output object files are identical. If we don't allow >>> ".long foo@PLT - .L4" in 64-bit, we shouldn't allow it in 32-bit. >> >> Why? .slong was introduced because of a peculiarity of x86-64. If that >> was straightforward to achieve, it may better not have been exposed to >> 16- and 32-bit code in the first place. While that ship has sailed, >> suddenly making its use mandatory for certain constructs even outside >> 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. .long should only ever use zero-extending ones; .slong was added such that want 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 adding new functionality we shouldn't extend existing flaws. Jan