https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92841
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org,
| |law at gcc dot gnu.org,
| |uros at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The reason for the xor is increased security, shorten the lifetime of the
dangerous value in a register as much as possible, so that e.g. signal handlers
or whatever else don't spill it somewhere from where an exploit could pick it
up.
The xor is done intentionally in the same pattern, so it is never split.
The pattern looks like:
(define_insn "@stack_protect_set_1_<mode>"
[(set (match_operand:PTR 0 "memory_operand" "=m")
(unspec:PTR [(match_operand:PTR 1 "memory_operand" "m")]
UNSPEC_SP_SET))
(set (match_scratch:PTR 2 "=&r") (const_int 0))
(clobber (reg:CC FLAGS_REG))]
""
"mov{<imodesuffix>}\t{%1, %2|%2, %1}\;mov{<imodesuffix>}\t{%2, %0|%0,
%2}\;xor{l}\t%k2, %k2"
[(set_attr "type" "multi")])
So, without compromising security, the only thing that could be done is add
pattern which would be similar to the above, except that it would use
match_operand instead of match_scratch for the second set and would use some
input operand which could say be another GPR or a constant and perhaps could
use a mode other than PTR if needed and peephole2 to match it. I think it
would be a bad idea to try to split it, such that the two modes would be in one
pattern and the mov would be another one, because then e.g. the scheduler could
move it away etc.
