musl/src/thread, branch v0.9.6 musl - an implementation of the standard library for Linux-based systems update mips cancellation-point syscall asm with 7-arg and r25 fixes 2012-09-15T06:24:12+00:00 Rich Felker dalias@aerifal.cx 2012-09-15T06:24:12+00:00 881868382a54b851b37d0b0f5f2d44f77af998a7 these fixes were already made to the normal syscall asm but not the cancellation point version. 
these fixes were already made to the normal syscall asm but not the
cancellation point version.
fix mips syscall_cp_asm code (saved register usage) 2012-09-09T04:59:30+00:00 Rich Felker dalias@aerifal.cx 2012-09-09T04:59:30+00:00 be48e22b424b6f858da0151a0b3b68bdb96b41ca 






further use of _Noreturn, for non-plain-C functions
2012-09-07T03:34:10+00:00

Rich Felker
dalias@aerifal.cx

2012-09-07T03:34:10+00:00

0c05bd3a9c165cf2f0b9d6fa23a1f96532ddcdb3

note that POSIX does not specify these functions as _Noreturn, because
POSIX is aligned with C99, not the new C11 standard. when POSIX is
eventually updated to C11, it will almost surely give these functions
the _Noreturn attribute. for now, the actual _Noreturn keyword is not
used anyway when compiling with a c99 compiler, which is what POSIX
requires; the GCC __attribute__ is used instead if it's available,
however.

in a few places, I've added infinite for loops at the end of _Noreturn
functions to silence compiler warnings. presumably
__buildin_unreachable could achieve the same thing, but it would only
work on newer GCCs and would not be portable. the loops should have
near-zero code size cost anyway.

like the previous _Noreturn commit, this one is based on patches
contributed by philomath.





note that POSIX does not specify these functions as _Noreturn, because
POSIX is aligned with C99, not the new C11 standard. when POSIX is
eventually updated to C11, it will almost surely give these functions
the _Noreturn attribute. for now, the actual _Noreturn keyword is not
used anyway when compiling with a c99 compiler, which is what POSIX
requires; the GCC __attribute__ is used instead if it's available,
however.

in a few places, I've added infinite for loops at the end of _Noreturn
functions to silence compiler warnings. presumably
__buildin_unreachable could achieve the same thing, but it would only
work on newer GCCs and would not be portable. the loops should have
near-zero code size cost anyway.

like the previous _Noreturn commit, this one is based on patches
contributed by philomath.







use restrict everywhere it's required by c99 and/or posix 2008
2012-09-07T02:44:55+00:00

Rich Felker
dalias@aerifal.cx

2012-09-07T02:44:55+00:00

400c5e5c8307a2ebe44ef1f203f5a15669f20347

to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.





to deal with the fact that the public headers may be used with pre-c99
compilers, __restrict is used in place of restrict, and defined
appropriately for any supported compiler. we also avoid the form
[restrict] since older versions of gcc rejected it due to a bug in the
original c99 standard, and instead use the form *restrict.







fix extremely rare but dangerous race condition in robust mutexes
2012-08-17T21:13:53+00:00

Rich Felker
dalias@aerifal.cx

2012-08-17T21:13:53+00:00

da8d0fc4fa3490f418a438b7e0830f9af312d41f

if new shared mappings of files/devices/shared memory can be made
between the time a robust mutex is unlocked and its subsequent removal
from the pending slot in the robustlist header, the kernel can
inadvertently corrupt data in the newly-mapped pages when the process
terminates. i am fixing the bug by using the same global vm lock
mechanism that was used to fix the race condition with unmapping
barriers after pthread_barrier_wait returns.





if new shared mappings of files/devices/shared memory can be made
between the time a robust mutex is unlocked and its subsequent removal
from the pending slot in the robustlist header, the kernel can
inadvertently corrupt data in the newly-mapped pages when the process
terminates. i am fixing the bug by using the same global vm lock
mechanism that was used to fix the race condition with unmapping
barriers after pthread_barrier_wait returns.







fix (hopefully) all hard-coded 8's for kernel sigset_t size
2012-08-10T02:52:13+00:00

Rich Felker
dalias@aerifal.cx

2012-08-10T02:52:13+00:00

2f437040e7911d9bef239588ea7ed6f4b9102922

some minor changes to how hard-coded sets for thread-related purposes
are handled were also needed, since the old object sizes were not
necessarily sufficient. things have gotten a bit ugly in this area,
and i think a cleanup is in order at some point, but for now the goal
is just to get the code working on all supported archs including mips,
which was badly broken by linux rejecting syscalls with the wrong
sigset_t size.





some minor changes to how hard-coded sets for thread-related purposes
are handled were also needed, since the old object sizes were not
necessarily sufficient. things have gotten a bit ugly in this area,
and i think a cleanup is in order at some point, but for now the goal
is just to get the code working on all supported archs including mips,
which was badly broken by linux rejecting syscalls with the wrong
sigset_t size.







retry on cas failures in sem_trywait
2012-07-24T04:51:36+00:00

Rich Felker
dalias@aerifal.cx

2012-07-24T04:51:36+00:00

07e62953c768f9f09485388c22ffaed98d11d676

this seems counter-intuitive since sem_trywait is supposed to just try
once, not wait for the semaphore. however, the retry loop is not a
wait. instead, it's to handle the case where the value changes due to
a simultaneous post or wait from another thread while the semaphore
value remains positive. in such a case, it's absolutely wrong for
sem_trywait to fail with EAGAIN because the semaphore is not busy.





this seems counter-intuitive since sem_trywait is supposed to just try
once, not wait for the semaphore. however, the retry loop is not a
wait. instead, it's to handle the case where the value changes due to
a simultaneous post or wait from another thread while the semaphore
value remains positive. in such a case, it's absolutely wrong for
sem_trywait to fail with EAGAIN because the semaphore is not busy.







avoid blx instruction which does not exist on armv4t or armv4
2012-07-15T00:15:02+00:00

Rich Felker
dalias@aerifal.cx

2012-07-15T00:15:02+00:00

7be3b5a073e77f1147acfa728725f9f81d20ceb0












fix several locks that weren't updated right for new futex-based __lock
2012-07-12T15:23:43+00:00

Rich Felker
dalias@aerifal.cx

2012-07-12T15:23:43+00:00

bbbe87e35cfeef593e23010e35528e722027567f

these could have caused memory corruption due to invalid accesses to
the next field. all should be fixed now; I found the errors with fgrep
-r '__lock(&', which is bogus since the argument should be an array.





these could have caused memory corruption due to invalid accesses to
the next field. all should be fixed now; I found the errors with fgrep
-r '__lock(&', which is bogus since the argument should be an array.







fix pthread_kill unlocking
2012-07-12T15:14:12+00:00

Rich Felker
dalias@aerifal.cx

2012-07-12T15:14:12+00:00

c89f130f39b413d1fb1733166ca63d694685c529

it had not been updated for the futex-based locks





it had not been updated for the futex-based locks