[PATCH v2] x86: Restore PC16 relocation overflow check

[Michael Matz]

Hello,

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

> The current linker assumes that PC16 is only used in 16-bit programs.  

Right, and it should continue doing so, and that acceptable use I would 
like to accept and encode in the psABI.

> Of course, it is wrong for 32-bit or 64-bit programs.


Ciao,
Michael.