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.