[PATCH v2] x86: Restore PC16 relocation overflow check

[Jan Beulich]

On 31.05.2021 15:04, Michael Matz wrote:
> Hello,
> 
> On Mon, 31 May 2021, H.J. Lu wrote:
> 
>>>>> We can change the psABI.  But changes should make sense in the
>>>>> abstract as well as being demanded by reality.  I think we have good
>>>>> cause to make PC16 conforming now, but I don't think we have good
>>>>> cause to make its semantic anything else from the obvious.  FWIW, my
>>>>> patch would be
>>>>>   https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/22
>>>>>
>>>>> Do you also want _8 and _16 (zero-extended I guess)?  _PC8
>>>>> (sign-extended)?
>>>>>
>>>>
>>>> Since there are 16-bit applications which expect PC16 behavior in
>>>> binutils 2.36, we can't change it without breaking them.
>>>
>>> Which change specifically would break them?  AFAICS any change in binutils
>>> will still result in the same binary output, so can you please explain?
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=27905
>>
>>> (I thought we are only talking about giving a meaning to PC16 in order to
>>> be able to make the linker depend on and hence check certain invariants)
>>>
>>>> We can update psABI to add a new PC16 relocation and leave the current
>>>> PC16 alone.
>>>
>>> Well, the current psABI makes PC16 use non-conforming, so strictly
>>> speaking we can do there whatever we want.  And even if that note of
>>> non-conformity were simply removed without any other change, it would
>>> still suggest a signed number (because, well, it's PC- _relative_, hence
>>> offset, hence signed).
>>>
>>> So, again, what will break if we make it explicit that it's a
>>> sign-extended number?
>>
>> It is not about the sign extension.
> 
> I will say it is, in so far as when sign-extending it overflows, whereas 
> with zero-extension it doesn't.  So we have the typical case of a 1.5 
> range value indeed, and can't require just sign-extension.

It isn't just 1.5, is it? A negative offset of -0xffff will similarly
wrap on hardware in 16-bit mode ...

Jan