The macro pthread_cleanup_push_defer_np in pthread.h has a misaligned
line continuation marker. This marker was previously aligned, but
recent changes have moved it out of alignment. This change realigns
the marker. This also reduces the diff against the hppa version of
pthread.h where the marker is aligned.
[BZ #14652]
When a thread waiting in pthread_cond_wait with a PI mutex is
cancelled after it has returned successfully from the futex syscall
but just before async cancellation is disabled, it enters its
cancellation handler with the mutex held and simply calling a
mutex_lock again will result in a deadlock. Hence, it is necessary to
see if the thread owns the lock and try to lock it only if it doesn't.
[BZ #14568]
* sysdeps/sparc/tls.h (DB_THREAD_SELF_INCLUDE): Delete.
(DB_THREAD_SELF): Use constants for the register offsets. Correct
the case of a 64-bit debugger with a 32-bit inferior.
[BZ #14417]
A futex call with FUTEX_WAIT_REQUEUE_PI returns with the mutex locked
on success. If such a successful thread is pipped to the cond_lock by
another spuriously woken waiter, it could be sent back to wait on the
futex with the mutex lock held, thus causing a deadlock. So it is
necessary that the thread relinquishes the mutex before going back to
sleep.
[BZ #14477]
Add an additional entry in the exception table to jump to
__condvar_w_cleanup2 instead of __condvar_w_cleanup for PI mutexes
when %ebx contains the address of the futex instead of the condition
variable.
Ref gcc.gnu.org/bugzilla/show_bug.cgi?id=52839#c10
Release barriers are needed to ensure that any memory written by
init_routine is seen by other threads before *once_control changes.
In the case of clear_once_control we need to flush any partially
written state.
There is nothing in the POSIX specification to disallow a
single-threaded program from cancelling itself, so we forcibly enable
multiple_threads to allow the next available cancellation point in the
thread to run.
Also added additional tests to cover various cancellation scenarios.
