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.
