[PATCH 0/3] x86: another take at PC16 reloc overflow checking

[H.J. Lu]

On Thu, Jun 17, 2021 at 8:29 AM Jan Beulich <jbeulich@suse.com> wrote:
>
> On 17.06.2021 17:25, H.J. Lu wrote:
> > On Thu, Jun 17, 2021 at 8:21 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>
> >> On 17.06.2021 17:17, H.J. Lu wrote:
> >>> On Thu, Jun 17, 2021 at 8:07 AM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>
> >>>> On 17.06.2021 16:59, H.J. Lu wrote:
> >>>>> On Mon, Jun 14, 2021 at 11:36 PM Jan Beulich <jbeulich@suse.com> wrote:
> >>>>>>
> >>>>>> As suggested the first patch introduces command line options, keeping
> >>>>>> default behavior as-is at least for now. It also extends this to PC32
> >>>>>> handling on x86-64, to allow covering 32-bit code in a 64-bit object
> >>>>>> file. The other two patches are cleanup noticed to be desirable while
> >>>>>> doing the main change.
> >>>>>>
> >>>>>> 1: x86: permit correct overflow checking for 16-bit PC-relative relocs
> >>>>>> 2: x86-64/ELF: use new reloc override model to deal with x32 special case
> >>>>>> 3: x86: drop redundant x86-64-code16-2 test
> >>>>>>
> >>>>>
> >>>>> I don't think a linker option to change PC16 relocation overflow is a good
> >>>>> idea.  If we really want to use PC16 with XBEGIN, we can add a new
> >>>>> relocation type.
> >>>>
> >>>> It was already said that a new reloc type comes with its own issues. Plus
> >>>> what about the relaxed PC32 overflow checking that the first patch also
> >>>> adds? And finally - patch 3 is, I think, independent of all of this.
> >>>
> >>> Let's make an XBEGIN with PC16 a separate issue.  Please submit a new
> >>> patch without the new linker option.
> >>
> >> I'm afraid I don't understand: A new patch doing what? Or do you mean I
> >> should re-submit patch 3 on its own (which is not going to be any
> >> different from what it is now, I've merely placed it last in the series
> >> as being pure cleanup)?
> >
> > A new patch set without new linker options to change PC16 relocation
> > overflow.
>
> And how do you suggest I do this, without using a different reloc type
> (which would first need agreeing on and defining)? The one reloc type
> is used two way that are incompatible, and the linker can't reliably
> tell apart the two cases, so it needs external aid.

There is no perfect solution.  We can add a new PC16 relocation for
XBEGIN or only use PC32 for XBEGIN.

-- 
H.J.