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

[yroux at gcc dot gnu.org]

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.