https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81863
--- Comment #14 from Yvan Roux <yroux at gcc dot gnu.org> --- (In reply to Ramana Radhakrishnan from comment #12) > No, this is too big a hammer. Yes, and it doesn't work with -cmse testcases. > 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. I agree, that was more or less my question comment #5 (and the reason why I didn't sent the patch to gcc-patches) > 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 think I tried that in first place, and it didn't fix one of the testcases, but maybe I used a wrong build tree, I'll re-test that. > 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.