summaryrefslogtreecommitdiff
path: root/arch/i386/bits/signal.h
AgeCommit message (Collapse)AuthorFilesLines
2017-01-04reduce impact of REG_* namespace pollution in x86[_64] signal.hRich Felker1-19/+38
when _GNU_SOURCE is defined, which is always the case when compiling c++ with gcc, these macros for the the indices in gregset_t are exposed and likely to clash with applications. by using enum constants rather than macros defined with integer literals, we can make the clash slightly less likely to break software. the macros are still defined in case anything checks for them with #ifdef, but they're defined to expand to themselves so that non-file-scope (e.g. namespaced) identifiers by the same names still work. for the sake of avoiding mistakes, the changes were generated with sed via the command: sed -i -e 's/#define *\(REG_[A-Z_0-9]\{1,\}\) *\([0-9]\{1,\}\)'\ '/enum { \1 = \2 };\n#define \1 \1/' \ arch/i386/bits/signal.h arch/x86_64/bits/signal.h arch/x32/bits/signal.h
2015-03-18fix MINSIGSTKSZ values for archs with large signal contextsRich Felker1-0/+5
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.
2014-03-18fix signal.h breakage from moving stack_t to arch-specific bitsRich Felker1-6/+6
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-18move signal.h definition of stack_t to arch-specific bitsRich Felker1-0/+6
it's different at least on mips. mips version will be fixed in a separate commit to show the change.
2013-03-23add deprecated SIGIOT alias for SIGABRTRich Felker1-0/+1
reportedly some programs (e.g. showkeys in the kbd package) use it.
2012-12-06move signal.h REG_* macros under _GNU_SOURCE protectionRich Felker1-20/+22
they were accidentally exposed under just baseline POSIX, which is a big namespace pollution issue. thankfully glibc only exposes them under _GNU_SOURCE, not under any of its other options, so omitting the pollution in the default _BSD_SOURCE profile does not hurt application compatibility at all.
2012-12-06bits/signal.h: add register names for x86(_64)rofl0r1-0/+21
glibc exposes them from ucontext.h. since that header includes signal.h, it is safe to put them into bits/signal.h, if _GNU_SOURCE is defined.
2012-11-25fixup mcontext stuff to expost gregset_t/fpregset_t as appropriateRich Felker1-4/+5
2012-11-23sigcontext/mcontext cleanup for arch-specific bitsRich Felker1-22/+26
with these changes, the members/types of mcontext_t and related stuff should closely match the glibc definitions. unlike glibc, however, the definitions here avoid using typedefs as much as possible and work directly with the underlying types, to minimize namespace pollution from signal.h in the default (_BSD_SOURCE) profile. this is a first step in improving compatibility with applications which poke at context/register information -- mainly debuggers, trace utilities, etc. additional definitions in ucontext.h and other headers may be needed later. if feature test macros are used to request a conforming namespace, mcontext_t is replaced with an opaque structure of the equivalent size and alignment; conforming programs cannot examine its contents anyway.
2012-11-23fix up leftover, incorrect NSIG definitions in arch-specific signal.hRich Felker1-1/+0
2012-11-21add back NSIG, removed from powerpc in last commit, but for all archsRich Felker1-0/+2
unlike the previous definition, NSIG/_NSIG is supposed to be one more than the highest signal number. adding this will allow simplifying libc-internal code that makes signal-related syscalls, which can be done as a later step. some apps might use it too; while this usage is questionable, it's at least not insane.
2012-05-22fix missing _BSD_SOURCE support in bits/*.hRich Felker1-2/+2
this is actually rather ugly, and would get even uglier if we ever want to support further feature test macros. at some point i may factor the bits headers into separate files for C base, POSIX base, and nonstandard extensions (the only distinctions that seem to matter now) and then the logic for which to include can go in the main header rather than being duplicated for each arch. the downside of this is that it would result in more files having to be opened during compilation, so as long as the ugliness does not grow, i'm inclined to leave it alone for now.
2011-09-19cleanup redundancy in bits/signal.h versionsRich Felker1-122/+10
2011-03-10make sigaltstack work (missing macros in signal.h, error conditions)Rich Felker1-0/+2
2011-02-20fill in some missing siginfo stuff in signal.hRich Felker1-5/+56
2011-02-18support the ugly and deprecated ucontext and sigcontext header stuff...Rich Felker1-0/+34
only the structures, not the functions from ucontext.h, are supported at this point. the main goal of this commit is to make modern gcc with dwarf2 unwinding build without errors. honestly, it probably doesn't matter how we define these as long as they have members with the right names to prevent errors while compiling libgcc. the only time they will be used is for propagating exceptions across signal-handler boundaries, which invokes undefined behavior anyway. but as-is, they're probably correct and may be useful to various low-level applications dealing with virtualization, jit code generation, and so on...
2011-02-15preparing build system to handle ports - step 1Rich Felker1-0/+107