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

[Jan Beulich <jbeulich@suse.com>]

On 09.03.2022 16:32, H.J. Lu wrote:
> On Wed, Mar 9, 2022 at 7:17 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> 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 ...
>>
> 
> If there is a real issue, we should fix it without a command-line
> option.  Can you use the input section name/flags to check it?

I don't see how - it's overwhelmingly likely all in .text.

Jan