Add signalfd() call to bionic.
Adding the signalfd call was done in 3 steps:
- add signalfd4 system call (function name and syscall
number) to libc/SYSCALLS.TXT
- generate all necessary headers by calling
libc/tools/gensyscalls.py. This patch is adding
the generated files since the build system
does not call gensyscalls.py.
- create the signalfd wrapper in signalfd.cpp and add
the function prototype to sys/signalfd.h
(cherry-pick of 0c11611c11, modified to
work with older versions of GCC still in use on some branches.)
Change-Id: I4c6c3f12199559af8be63f93a5336851b7e63355
The MIPS toolchain can't generate them because they're incompatible
with the MIPS ABI (which requires .dynsym match the GOT, while GNU-style
requires .dynsym to be sorted by hash code), so there's nothing to test.
Change-Id: I2220f452fe6fe595ec1312544cc741dd390a36a5
Spotted while running the tests on MIPS, where sigset_t is
actually large enough. The bits in sigset_t are used such that
signal 1 is represented by bit 0, so the range of signals is
actually [1, 8*sizeof(sigset_t)]; it seems clearer to reword
the code in terms of valid bit offsets [0, 8*sizeof(sigset_t)),
which leads to the usual bounds checking idiom.
Change-Id: Id899c288e15ff71c85dd2fd33c47f8e97aa1956f
Previously we'd been relying on getting the machine-specific <endian.h>
instead of the top-level <endian.h>, and <sys/endian.h> was basically broken.
Now, with this patch and the previous patch we should have <endian.h>
and <sys/endian.h> behaving the same. This is basically how NetBSD's endian.h
works, and was probably how ours was originally intended to work.
Bug: http://code.google.com/p/android/issues/detail?id=39824
Change-Id: I71de5a507e633de166013a658b5764df9e1aa09c
raise() should use pthread_kill() in a pthreads environment.
For bionic this means it should always be used.
Change-Id: Ic679272b664d2b8a7068b628fb83a9f7395c441f
These checks haven't been as useful as I hoped, and it's
causing a false positive finding. Remove the overlap
compile time checks.
Change-Id: I5d45dde10ae4663d728230d41fa904adf20acaea
You could argue that this is hurting people smart enough to have manually
allocated a large-enough sigset_t, but those people are smart enough to
implement their own sigset functions too.
I wonder whether our least unpleasant way out of our self-inflicted 32-bit
cesspool is to have equivalents of _FILE_OFFSET_BITS such as _SIGSET_T_BITS,
so calling code could opt in? You'd have to be careful passing sigset_t
arguments between code compiled with different options.
Bug: 5828899
Change-Id: I0ae60ee8544835b069a2b20568f38ec142e0737b
