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

Jan Beulich jbeulich@suse.com
Thu Jun 17 15:29:24 GMT 2021


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.

Jan



More information about the Binutils mailing list