On 06/20/2017 02:21 AM, Eric Botcazou wrote: >> Out of curiousity, does the old Alpha/VMS stack-checking API meet the >> requirements? From what I recall, I think it does. > > No, it's the usual probe-first-and-then-allocate strategy and Jeff rejects it > because of valgrind. I'd personally rather change valgrind but... I'm torn here. It'd certainly be a hell of a lot easier to punt this to valgrind, but with the issues I just couldn't get comfortable with that.
We're probing pages which are potentially unmapped and far away from the stack pointer. The kernel and/or valgrind has to look at the reference and make a guess whether or not it's really a request for more stack or a wild pointer -- and there's no real good way to tell the difference. Thus we're dependent upon the heuristics used by the kernel and valgrind and we're dependent on those heuristics essentially being the same (and I'm certain they are not at this time :-) One could also argue that these probes are undefined behavior precisely because they potentially hit pages unmapped pages far away from the stack pointer. Any probing beyond the stack pointer is also going to trigger a valgrind warning. Valgrind has some support avoiding the warning if a reference hits the red zone -- but these probes can be well beyond the red zone. In a world where distros may be turning on -fstack-check=<whatever> by default, valgrind has to continue to work and not generate an unreasonable number of false positive warnings else the tool becomes useless. Jeff
