Commit Graph

4 Commits

Author SHA1 Message Date
Rich Felker d5a5045382 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.
2015-03-18 00:31:37 -04:00
Rich Felker 9505bfbc40 fix signal.h breakage from moving stack_t to arch-specific bits
in the previous changes, I missed the fact that both the prototype of
the sigaltstack function and the definition of ucontext_t depend on
stack_t.
2014-03-18 23:27:45 -04:00
Rich Felker bd5f221eaa move signal.h definition of stack_t to arch-specific bits
it's different at least on mips. mips version will be fixed in a
separate commit to show the change.
2014-03-18 23:12:40 -04:00
Rich Felker aacd348637 rename superh port to "sh" for consistency
linux, gcc, etc. all use "sh" as the name for the superh arch. there
was already some inconsistency internally in musl: the dynamic linker
was searching for "ld-musl-sh.path" as its path file despite its own
name being "ld-musl-superh.so.1". there was some sentiment in both
directions as to how to resolve the inconsistency, but overall "sh"
was favored.
2014-02-27 22:03:25 -05:00