https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83302
--- Comment #5 from Florian Weimer ---
FWIW, -fstack-clash-protection avoids these issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83302
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83302
--- Comment #3 from Michael Matz ---
In any case, this is not something that GCC could do anything about. A probe
necessarily has to be a write, and writing to something not belonging to own
stack (or guard page) will always have this problem of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83302
--- Comment #2 from Michael Matz ---
I guess the problem described in https://lkml.org/lkml/2017/11/10/188 is, that
the stack probe itself accesses a page which _doesn't_ belong to this threads
stack, but to something else. golang seems to use t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83302
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target|x86_64--n
