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 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.

-- 
H.J.