[PATCH v2] x86: Restore PC16 relocation overflow check

[Jan Beulich]

On 31.05.2021 17:16, Michael Matz wrote:
> Hello,
> 
> On Mon, 31 May 2021, Jan Beulich wrote:
> 
>>> Which is exactly why _that_ should be flagged as error by the linker as a 
>>> real overflow.  Whereas a both-extension that preserves the value is 
>>> acceptable in the right mode (and hence should not be flagged by the 
>>> linker as a problem).
>>>
>>> This is basically what I would like the psABI to say, displacements from 
>>> -0xffff to 0xffff are acceptable, larger or smaller ones aren't.
>>>
>>> Do you agree with that?
>>>
>>>>> So, what we can say in the psABI is that the value should match the
>>>>> original value when either sign- or zero-extended.  That still rules out
>>>>> "real" overflows (and checking for that makes sense, because also at
>>>>> runtime this won't work in any mode), but allows for this vague-extension
>>>>> to be relied upon.  Would that work for you?
>>>>
>>>> The issue is how linker should handle overflow for PC16.
>>>
>>> I think as per above.  An value within [-0xffff,0xffff] (mathematically, 
>>> i.e. the 32 or 64 bit value of the computation S+A-P) is defined as not 
>>> overflowing.  The linker basically needs to assume that the author knew 
>>> what he was doing when using a PC16 offset and only needs to flag things 
>>> that simply cannot be made to work (like e.g. jumping 0x12345 bytes 
>>> forward).
>>
>> While the ABI is free to state what it wants, such a wide range is not 
>> very useful when the relocation is used outside of 16-bit mode.
> 
> Well, as it stands the relocation needs to support uses within and outside 
> 16-bit mode, and the linker can't differ between those, so what's 
> acceptable needs to be the union of all ranges.
> 
>> The main need for the overflow detection is when it's out of range by 
>> just a little (e.g. because of some piece of code or data having grown 
>> just enough to bring it out of range).
> 
> But out of _what_ range?  You are saying that [-0xffff,0xffff] is too 
> broad, what range do you want?  (I don't think you can get away with a 
> smaller range with PC16 in the x86-64 psABI, but for completeness)

The true disp16 range - [-0x8000,+0x7fff]. As said before, for the
purposes of 32- and 64-bit code (and data), this (or a new, proper
reloc type) needs to match PC32 allowing [-0x80000000,+0x7fffffff].
And obviously this also ought to match PC8, allowing [-0x80,+0x7f].

Also note how PC8's current handling in bfd does _not_ fit 16-bit
code (wrapping at the 64k boundary not being accounted for).

>> This is what my change was about, which - aiui - H.J. has meanwhile 
>> reverted.
> 
> If your change flagged values within [0x8000,0xffff] or [-0xffff,-0x8001] 
> by default then I think the reversal was justified, those need to be 
> continued to be accepted, for better or worse.

Interesting - I took your initial reply to H.J. to mean the opposite.
Obviously a misunderstanding then ...

Jan