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

On 31.07.2026 23:03, H.J. Lu wrote:
> On Fri, Jul 31, 2026 at 6:55 PM Jan Beulich <[email protected]> wrote:
>>
>> 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.
> 
> Given that there are no issues with ".long foo - .L4",
> ".long foo1@PLT - .L4" should have no issues at all.
> If you believe that it isn't true, please show me a case.

WDYM by "there are no issues"? There is a very obvious issue: It is wrong
to assemble without error. Hence "please show me a case" is an impossible
thing to ask for. Any possible use is wrong (until such time that a
suitable relocation type is added, which very likely is "never").

The very, very farthest I might go to make a compromise would be for the
diagnostic to be a warning in place of an error. Yet that would still feel
wrong to me.

Jan