c-stack and Irix

[Eric Blake]

I've finally figured out why c-stack is being finicky on Irix 5.3 [1].  POSIX 
requires that sigaltstack be given ss_sp pointing to the smallest address in 
the alternate stack.  But Irix is non-compliant, and treats ss_sp as the 
starting address of the stack (which, since it grows down, makes it the largest 
address in the stack).  From their man page for sigaltstack:

 The stack grows downward from high to lower addresses.  The following
     code fragment is typically used to allocate an alternate stack.

          if ((sigstk.ss_sp = (char *)malloc(SIGSTKSZ)) == NULL)
               /* error return */;
          sigstk.ss_sp += SIGSTKSZ - 1;
               /* adjust ss_sp to point to base of stack */
          sigstk.ss_size = SIGSTKSZ;

This explains why Tom and I were having such a hard time in debugging c-stack 
code - the stack overflow handler was often triggering a secondary SIGSEGV as 
it traversed outside the bounds of the alternate stack, because we were setting 
up the alternate stack with the wrong bound per Irix conventions.

Before m4 was converted over to use c-stack, m4's stackovf.c worked around this 
issue by allocating 2*SIGSTKSZ bytes, then passing the midway point of the 
overallocation to sigaltstack, compared to c-stack's current approach of just 
allocating SIGSTKSZ bytes.  I'm debating about using the same workaround, or 
whether it is worth trying to write a configure-time test that checks for which 
side of the alternate stack is visited first in order add #ifdefs to set ss_sp 
correctly and avoid allocating the extra SIGSTKSZ bytes.  Any preferences?

Bruno, this means that libsigsegv 2.6 is buggy in handling sigsegv on platforms 
like Irix 5.3 (even though the tests currently pass, it is by sheer luck, 
because you are corrupting the contents of the stack outside of the area 
reserved for your stack-allocated alternate stack).  Maybe you should make the 
stackoverflow1.c test be more robust, by allocating some stack variables on 
either side of the alternate stack, setting them to known patterns, and 
checking that they have not been corrupted when longjmp'ing back out of the 
overflow handler.  Or maybe add a test that mmap's the alternate stack, such 
that exceeding the bounds of the alternate stack will indeed cause a definite 
segv, rather than a luck-of-the-draw clobbering of unrelated but allocated 
memory.

[1] http://lists.gnu.org/archive/html/bug-m4/2008-09/msg00014.html

-- 
Eric Blake