> But then valgrind won't be able to find bugs in the code (storing and later > reading stuff into the volatile parts of the stack that could be overwritten > by any asynchronous signal). GCC had various bugs in this area and > valgrind has been able to report those. Unless the probe instruction is > sufficiently magic that it won't usually appear in other code.
Right, maybe this magic aspect was the reason why it was initially implemented like that for Cygwin, at least you know that orl $0 is meant to be special. > Only checking loads below the stack is not sufficient, some buggy code could > e.g. store some data below stack pointer (below red zone if any), then > subtract stack and then try to read it, etc. > > Not to mention that it isn't just false positive messages with current > valgrind on -fstack-check code, e.g. on ppc64 it just crashes. The reasoning seems weird though since, apart from x86/x86-64, you're going to gratuitously inflict this painful "moving sp" thing to every program compiled on Linux because of just one tool that you can adapt. -- Eric Botcazou
