[PATCH v2] x86: Restore PC16 relocation overflow check

[H.J. Lu]

On Mon, May 31, 2021 at 5:27 AM Michael Matz <matz@suse.de> wrote:
>
> Hello,
>
> On Fri, 28 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.  It is about overflow behavior.
In 16-bit mode, PC16 can wrap around.

-- 
H.J.