This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 17/18] x86, pthread_cond_*wait: Do not depend on %eax not being clobbered
- From: Florian Weimer <fweimer at redhat dot com>
- To: Nix <nix at esperi dot org dot uk>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 10 Mar 2016 14:03:45 +0100
- Subject: Re: [PATCH 17/18] x86, pthread_cond_*wait: Do not depend on %eax not being clobbered
- Authentication-results: sourceware.org; auth=none
- References: <1457445064-7107-1-git-send-email-nix at esperi dot org dot uk> <1457445064-7107-18-git-send-email-nix at esperi dot org dot uk>
On 03/08/2016 02:51 PM, Nix wrote:
> From: Nick Alcock <nick.alcock@oracle.com>
>
> The x86-specific versions of both pthread_cond_wait and
> pthread_cond_timedwait have (in their fall-back-to-futex-wait slow
> paths) calls to __pthread_mutex_cond_lock_adjust followed by
> __pthread_mutex_unlock_usercnt, which load the parameters before the
> first call but then assume that the first parameter, in %eax, will
> survive unaffected. This happens to have been true before now, but %eax
> is a call-clobbered register, and this assumption is not safe: it could
> change at any time, at GCC's whim, and indeed the stack-protector canary
> checking code clobbers %eax while checking that the canary is
> uncorrupted.
>
> So reload %eax before calling __pthread_mutex_unlock_usercnt. (Do this
> unconditionally, even when stack-protection is not in use, because it's
> the right thing to do, it's a slow path, and anything else is dicing
> with death.)
>
> v5: New.
>
> * sysdeps/unix/sysv/linux/i386/pthread_cond_timedwait.S: Reload
> call-clobbered %eax on retry path.
> * sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S: Likewise.
Nice catch. This should go in separately because it's independent of
the stack protector work.
Thanks,
Florian