[PATCH v2] x86: Restore PC16 relocation overflow check

[Michael Matz]

Hello,

On Mon, 31 May 2021, Jan Beulich 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 ...

Err, right, of course, underflow can also happen.  So the acceptable range 
of values is [-0xffff,0xffff] which is more than those values that are 
value-preserved under sign- or zero-extension.


Ciao,
Michael.