[Bug target/81863] [7 regression] -mword-relocations is unreliable

["ramana at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863

--- Comment #12 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
(In reply to Yvan Roux from comment #8)
> On 7 branch the following should fix the issue, but as I mentioned in
> comment #5, maybe TARGET_USE_MOVT is a better place to do the checking but
> this will need some 
> s/TARGET_HAVE_MOVT/TARGET_USE_MOVT/ 
> 
> --- a/gcc/config/arm/arm.h
> +++ b/gcc/config/arm/arm.h
> @@ -272,7 +272,8 @@ extern tree arm_fp16_type_node;
>                                  && arm_arch_notm)
>  
>  /* Nonzero if this chip provides the MOVW and MOVT instructions.  */
> -#define TARGET_HAVE_MOVT       (arm_arch_thumb2 || arm_arch8)
> +#define TARGET_HAVE_MOVT       ((arm_arch_thumb2 || arm_arch8) \
> +                                && !target_word_relocations)
>  
>  /* Nonzero if this chip provides the CBZ and CBNZ instructions.  */
>  #define TARGET_HAVE_CBZ                (arm_arch_thumb2 || arm_arch8)

No, this is too big a hammer. 

It will disable movw / movt for constants and we don't want that. The aim of
any patch should be to turn off movw / movt only for symbolic references.
Additionally I think we need to rationalize the use of TARGET_USE_MOVT vs
TARGET_HAVE_MOVT in the backend.

(In reply to Yvan Roux from comment #4)
> My quick understanding is that to prevent LRA generating invalid high/lo_sum
> code, arm_valid_symbolic_address_p (introduced at r227129) needs to be
> strengthen and check that target_word_relocations is not defined when an
> addend is present.

That certainly appears to be a better approach prima-facie and a quick
experiment with a 


if (target_word_relocations)
  return false;

in arm_valid_symbolic_address () appears to deal with the issue. 

I'll try and come up with a patch a bit later to try this out - I'm not at my
usual machine today to actually throw it through some testing.

The problem IIUC is that LRA automatically now generates high / lo_sum variants
and thus the patterns need to be disabled through another interface and thus we
need to prevent the generation of the lo_sum / high in that interface as I
don't think that generation happens through the standard mov<mode> patterns. 

In general also having constant pools is a bad thing security wise - Arnd, can
you remind me again why the kernel needs -mword-relocations to work instead of
teaching the module loader more with the new relocations - it's been more than
10 years since movw / movt went in and I'm curious as to why the kernel hasn't
at all moved forward.