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

[Jan Beulich]

On 17.06.2021 17:36, H.J. Lu wrote:
> 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.

That's not answering my question, really. I can't implement anything
else as long as there is no new relocation. I'm also not going to do
any work "just in case" such a reloc type might appear. I still don't
know how I can fulfill your request of "submitting a new patch without
the new linker option".

Jan