[PATCH v2] x86: Restore PC16 relocation overflow check

[Michael Matz]

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)

> 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.


Ciao,
Michael.