The kernel uses the very misleading name "si_tid", but glibc uses the more
intention-revealing "si_timerid". We should let people use that.
(Added because I wanted to improve SI_TIMER siginfo_t dumping in strace.)
Change-Id: Ib626cdd3b57a6afb276a15753a237b4e81ec45e3
We don't need quite so much duplication because we already have a way
to get the signal number from its name, and that already copes with the
fact that the mips/mips64 numbers are different from everyone else's.
Also remove sys_signame from LP64. glibc doesn't have this BSD-ism.
Change-Id: I6dc411a3d73589383c85d3b07d9d648311492a10
Our sigset_t definition hasn't been tied to our NSIG definition since we
switched to uapi headers, so we can now fix it without breaking the LP32 ABI.
The kernel uapi headers define and use _NSIG, so we need to have our scripts
rename the kernel's definitions out of the way, then we can define _NSIG
and NSIG in terms of the kernel's off-by-one value.
Bug: 12938442
Change-Id: Ic7c86fd5be5ad1d822f7b2b1d88c8a0d70a1ac0f
<time.h> didn't need to copy the cruft from <signal.h>, and
<signal.h> only needs the uid_t hack when it's not using
uapi headers.
pthread_exit.cpp should include what it uses.
Change-Id: I836c36abe0f0a781d41fc425b249d1c7686bb124
Also clean up <signal.h> and revert the hacks that were necessary
for 64-bit in linker/debugger.cpp until now.
Change-Id: I3b0554ca8a49ee1c97cda086ce2c1954ebc11892
sigismember, sigaddset, and sigdelset had mixed code and declarations
which are not allowed in C90 and before.
Change-Id: I662af944fc1489e34bed228ce592e41f50d00e17
Signed-off-by: Erik Gilling <konkers@android.com>
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
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
This patch updates the C library headers to provide ucontext_t
definitions for three architectures.
+ Fix <signal.h> to always define 'struct sigcontext'.
The new declarations are announced with new macros defined in
<sys/cdefs.h> in order to make it easier to adapt client code
that already defines its own, incompatible, versions of the
structures seen here.
http://code.google.com/p/android/issues/detail?id=34784
Change-Id: Ie78c48690a4ce61c50593f6c39639be7fead3596
After this change, SIGRTMAX will be set to 64 (instead of 32 currently).
Note that this doesn't change the fact that our sigset_t is still defined
as a 32-bit unsigned integer, so most functions that deal with this type
won't support real-time signals though.
Change-Id: Ie1e2f97d646f1664f05a0ac9cac4a43278c3cfa8
This matches recent changes in the NDK header.
We enclose missing functions in #if 0 .. #endif blocks
with a clear "MISSING" in comments in order to locate
them later.
Change-Id: I87b3a62e777897e75c9243360fb0a82bcc53d9fb
