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

[Jan Beulich]

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.

Jan