[Bug target/85434] Address of stack protector guard spilled to stack on ARM

[thopre01 at gcc dot gnu.org]

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

--- Comment #8 from Thomas Preud'homme <thopre01 at gcc dot gnu.org> ---
(In reply to Thomas Preud'homme from comment #7)
> (In reply to Thomas Preud'homme from comment #6)
> > (In reply to Thomas Preud'homme from comment #3)
> > > 
> > > My feeling is that the target patterns should also do the address
> > > computation, ie stack_protect_set and stack_protect_test would take that MEM
> > > of symbol_ref instead of expanding it first.
> > 
> > The more I think about it the more I think it's the only way to guarantee
> > the guard's address does not end up in a register that could be spilled. The
> > spilling itself is more likely to happen when reading the GOT entry that
> > holds the guard's address is not represented by an UNSPEC because then the
> > address computed when setting the canari is reused when doing the
> > comparison. UNSPEC seems to prevent that (even though it's not
> > UNSPEC_VOLATILE).
> 
> I'm experimenting with a patch to mark the MEM to access the GOT entry as
> volatile in ARM backend in order to prevent CSE. It works on this PR's
> testcase so will give bootstrap and regression testing a try. As I said,
> this doesn't fully solve the underlying issue IMO but together with
> implementation of stack_protect_set and stack_protect_test in ARM it should
> make stack protector as reliable on ARM targets as on AArch64.

Found out the approach needs further changes for Thumb-1 because a PIC access
is done in several instructions. I'm addressing those at the moment.