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

["H.J. Lu" <hjl.tools@gmail.com>]

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?

-- 
H.J.