On 06/20/2017 02:37 PM, Eric Botcazou wrote: >> 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. I don't see MOVING_SP as painful, except perhaps on aarch64. On something like PPC MOVING_SP turns out to be exceedingly clean.
jeff
