fix MINSIGSTKSZ values for archs with large signal contexts
authorRich Felker <dalias@aerifal.cx>
Wed, 18 Mar 2015 03:12:48 +0000 (23:12 -0400)
committerRich Felker <dalias@aerifal.cx>
Wed, 18 Mar 2015 04:31:37 +0000 (00:31 -0400)
commitd5a5045382315e36588ca225889baa36ed0ed38f
treeb727e3ec85f49384a50f09568c62c0bb9410b6bd
parent76fd01177a32d602bc5ee7bd7ba65316adbae611
fix MINSIGSTKSZ values for archs with large signal contexts

the previous values (2k min and 8k default) were too small for some
archs. aarch64 reserves 4k in the signal context for future extensions
and requires about 4.5k total, and powerpc reportedly uses over 2k.
the new minimums are chosen to fit the saved context and also allow a
minimal signal handler to run.

since the default (SIGSTKSZ) has always been 6k larger than the
minimum, it is also increased to maintain the 6k usable by the signal
handler. this happens to be able to store one pathname buffer and
should be sufficient for calling any function in libc that doesn't
involve conversion between floating point and decimal representations.

x86 (both 32-bit and 64-bit variants) may also need a larger minimum
(around 2.5k) in the future to support avx-512, but the values on
these archs are left alone for now pending further analysis.

the value for PTHREAD_STACK_MIN is not increased to match MINSIGSTKSZ
at this time. this is so as not to preclude applications from using
extremely small thread stacks when they know they will not be handling
signals. unfortunately cancellation and multi-threaded set*id() use
signals as an implementation detail and therefore require a stack
large enough for a signal context, so applications which use extremely
small thread stacks may still need to avoid using these features.
arch/aarch64/bits/signal.h
arch/arm/bits/signal.h
arch/i386/bits/signal.h
arch/microblaze/bits/signal.h
arch/mips/bits/signal.h
arch/or1k/bits/signal.h
arch/powerpc/bits/signal.h
arch/sh/bits/signal.h
arch/x32/bits/signal.h
arch/x86_64/bits/signal.h
include/signal.h