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

On 03.08.2026 10:52, H.J. Lu wrote:
> On Mon, Aug 3, 2026 at 3:35 PM Jan Beulich <[email protected]> wrote:
>>
>> On 03.08.2026 09:22, H.J. Lu wrote:
>>> On Mon, Aug 3, 2026 at 2:44 PM Jan Beulich <[email protected]> wrote:
>>>>
>>>> On 01.08.2026 15:47, Maciej W. Rozycki wrote:
>>>>> On Sat, 1 Aug 2026, H.J. Lu wrote:
>>>>>
>>>>>>>>> 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.
>>>>>
>>>>>  I gather this is about the overflow case, handled differently depending
>>>>> on the signedness or the lack of, of the datum relocated by the static
>>>>> linker or dynamic loader as appropriate.
>>>>>
>>>>>  Jan, please correct me if I'm wrong since commit d182319b0955 has no
>>>>> change description and there's no documentation for `.slong' in the GAS
>>>>> manual either.  What are the x86 psABI ELF relocation types corresponding
>>>>> to `.long' and `.slong' respectively in this context?
>>>>
>>>> For .long there simply is no correct relocation type to use for PLT (and,
>>>> fwiw, simple PC-relative) expressions. The correct type to use is
>>>> R_X86_64_PLT32 (and R_X86_64_PC32 for the simple PC-rel case).
>>>>
>>>> For the simple PC-rel case we simply cannot require use of .slong, as we've
>>>> been accepting .long (then guessing that .slong was meant). Else we'd very
>>>> likely break existing code. Since @PLT was rejected so far when used with
>>>> .long and .slong, doing better here is imo very desirable (if not
>>>> imperative).
>>>>
>>>
>>> Because assembler has been correctly generating R_X86_64_PC32 for
>>> ".long foo - .L4",
>>
>> What, again, does "correctly" mean here? We need to retain this incorrect
>> behavior, yes, but that doesn't mean we should extend it to other constructs.
> 
> Call it "incorrect behavior"  is your opinion.  I certainly disagree.
> Given that it
> has been used this way from day one, it is the correct behavior for x86-64.

How can it be correct if it would break if a suitable relocation was introduced?
Just because it has been this way from the start of x86-64 doesn't mean it was
right. There are many things which needed correction later one One of them being
the original lack of .slong.

Jan