DavidSpickett added a comment. A lot of these system registers are going to be unsuitable for the stack canary. They're either read only, they have fixed bits, or they'll get overwritten by various system events.
I'm not suggesting we audit this list for those things, what seems reasonable to me is just to support the ones that the Linux kernel uses. (what GCC allows I'm not sure) https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/AArch64-Options.html -mstack-protector-guard=guard -mstack-protector-guard-reg=reg -mstack-protector-guard-offset=offset Generate stack protection code using canary at guard. Supported locations are ‘global’ for a global canary or ‘sysreg’ for a canary in an appropriate system register. With the latter choice the options -mstack-protector-guard-reg=reg and -mstack-protector-guard-offset=offset furthermore specify which system register to use as base register for reading the canary, and from what offset from that base register. There is no default register or offset as this is entirely for use within the Linux kernel. So if kernel builds are using a small subset of registers, just check for those. Otherwise we've got another duplicated list that we (Arm) will probably forget to update anyway when new registers are added. Either way it's one more stick on the "why doesn't clang just use the backend info" fire, but it's smaller at least if we limit the registers. E.g. error: invalid value 'foo' in 'mstack-protector-guard-reg=','for AArch64' valid values are sp_el1 sp_el2 Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D101327/new/ https://reviews.llvm.org/D101327 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
