[PATCH v2 1/3] x86-64/ELF: permit relaxed overflow checking for 32-bit PC-relative relocs

[Jan Beulich]

On 09.03.2022 16:08, H.J. Lu wrote:
> On Wed, Mar 9, 2022 at 6:39 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 09.03.2022 15:27, H.J. Lu wrote:
>>> On Wed, Mar 9, 2022 at 12:21 AM Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 04.03.2022 15:18, H.J. Lu wrote:
>>>>> On Fri, Mar 04, 2022 at 02:34:58PM +0100, Jan Beulich wrote:
>>>>>> --- a/ld/ld.texi
>>>>>> +++ b/ld/ld.texi
>>>>>> @@ -1372,6 +1372,12 @@ missing properties in input files.  @opt
>>>>>>  the linker issue an error for missing properties in input files.
>>>>>>  Supported for Linux/x86_64.
>>>>>>
>>>>>> +@item lax-pcrel-relocs
>>>>>> +Relax relocation overflow checks for certain 32-bit PC-relative relocations
>>>>>> +which, when used by 32-bit code inside a 64-bit object, may require a
>>>>>> +larger range of values to be considered valid.
>>>>>> +Supported for x86-64 ELF targets.
>>>>>> +
>>>>>
>>>>> I think the check should be turned on automatically.  Can you use a GNU
>>>>> property bit to tell linker that a larger range of values should be
>>>>> checked for R_X86_64_PC32
>>>>
>>>> I'm not convinced that would be desirable - the relaxed checking, after
>>>> all, also affects relocations to 64-bit mode. Hence certain overflows
>>>> won't be detected anymore. Therefore I'd expect people to make use of
>>>> the new option only if they really have any affected relocations in
>>>> 32-bit code. Additionally there's no way I can see to set such a
>>>> property indicator when encountering the relocations in question only
>>>> in data definitions, unless you wanted to tie the setting of the
>>>> indicator to the mere use of .code{16,32} anywhere in the source (which
>>>> would feel way to aggressive to me). IMO this level of control can only
>>>> be achieved via command line option (without (a) becoming much more
>>>> intrusive or (b) introducing new relocation types).
>>>
>>> A new relocation type sounds better.
>>
>> We've been there before with PC16 - there are enough arguments against
>> introducing new types. I also never had the intention to propose ABI
>> extensions.
>>
> 
> A command-line option isn't user friendly.  On the other hand, why
> now?  The issue has been there forever.

Because earlier on no-one cared to think about the issue? This really
should have been considered when the ABI was initially written. _That_
would then also have been the time to introduce separate relocation
types. Now we need to apply workarounds ...

Jan