[PATCH v2] x86: Restore PC16 relocation overflow check

[Jan Beulich]

On 31.05.2021 16:36, Michael Matz wrote:
> On Mon, 31 May 2021, H.J. Lu wrote:
>>>>> 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 is about overflow behavior.  In 16-bit mode, PC16 can wrap around.
>>>
>>> So, let's look at the example you had in the above PR:
>>>
>>> [hjl@gnu-cfl-2 pr27905]$ cat rom.s
>>>         .code16gcc
>>>         .text
>>>         .section        .text.default_process_op.isra.0,"ax",@progbits
>>> default_process_op.isra.0:
>>>         ret
>>>         .section        .text.mpt_scsi_process_op,"ax",@progbits
>>> mpt_scsi_process_op:
>>>         jmp     default_process_op.isra.0
>>> ...
>>> .text.default_process_op.isra.0 0x737c : { *(.text.default_process_op.isra.0) }
>>> .text.mpt_scsi_process_op 0xf869 : { *(.text.mpt_scsi_process_op) }
>>>
>>> The offset between both sections is 0x84ed, which indeed can't be
>>> sign-extended to the same value in 16 bit.  But with wrap-around (and
>>> hence non-extension) it of course fits.  A real overflow would occur
>>> when the sections would be, say, 0x12345 bytes apart.
>>
>> 16-bit programs can't have 0x12345 displacement.
> 
> 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. 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). This is what my change was about,
which - aiui - H.J. has meanwhile reverted.

Jan