> But what you end up depending on is undocumented behavior of a > particular kernel implementation. That seems rather unwise.
And it's the single example of such a thing in the entire codebase? I don't know the code of the sanitizer much, but from the outside it looks full of similar tricks... > Which ABIs have that property? I'll be the first to admit that I've > purged much of my weird ABI memories. The original Alpha ABI mentioned by Richard IIRC for example. > Supporting ABIs which force us into a probe, then allocate strategy is > actually easy. We can use the existing -fstack-check code, but use the > value 0 for STACK_CHECK_PROTECT. > > Just replace all uses of STACK_CHECK_PROTECT with calls to a wrapper. > > The wrapper looks like > > if (magic_flag) > return STACK_CHECK_PROTECT; > else > return 0; > > That's precisely what we were planning to do prior to bumping against > the valgrind issues. That indirection makes it easy to ensure we didn't > change the behavior of the existing stack-check for Ada, but also allows > us to change the behavior for the new stack checking option. Yes, that would seem the most straightforward thing to do modulo Valgrind. > Ah, so if you're running on an alternate stack, then why probe ahead of > need? I thought the whole point of probing a couple pages ahead as to > ensure you could take the signal the Ada. We run on the alternate stack only when we do _not_ probe ahead, i.e. on x86/x86-64 Linux. > I've also wondered if a 2 page guard would solve some of these problems. > In the event of stack overflow, the kernel maps in one of the two pages > for use by the signal handler. But changing things at this point may > not be worth the effort. That was exactly the strategy used by Tru64 (so you needed to manually unmap the page after you had recovered from the overflow). -- Eric Botcazou
