Re: [RFCv2] Add pthread_cond_timedwaitonclock_np

[Mike Crowe <mac at mcrowe dot com>]

On Wednesday 05 August 2015 at 21:50:47 +0000, Joseph Myers wrote:
> On Wed, 5 Aug 2015, Mike Crowe wrote:
> 
> > diff --git a/nptl/pthread_cond_timedwait.c b/nptl/pthread_cond_timedwait.c
> > index 10b0a61..cdca8e0 100644
> > --- a/nptl/pthread_cond_timedwait.c
> > +++ b/nptl/pthread_cond_timedwait.c
> > @@ -49,8 +49,9 @@ struct _condvar_cleanup_buffer
> >  };
> >  
> >  int
> > -__pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex,
> > -			  const struct timespec *abstime)
> > +pthread_cond_timedwaitonclock_np (pthread_cond_t *cond, pthread_mutex_t *mutex,
> > +				  clockid_t clockid,
> > +				  const struct timespec *abstime)
> 
> I would have expected adding a strong definition of a non-POSIX function 
> to the source file defining a POSIX function to cause linknamespace test 
> failures - how was this patch tested?

I ran "make check" and "make check-abi" on x86_64, i686 and armhf.

I also applied the patch (with minor tweaks) to our OpenEmbedded build
(which is currently using glibc-2.20) along with the associated libstdc++
changes and tested the combination on i686, mipsel and armhf.

Is renaming the function definition to __pthread_cond_timedwaitonclock_np
and adding a weak alias to pthread_cond_timedwaitonclock sufficient to
resolve the underlying problem?

(I also spotted whilst investigating this that pthread_cond_timedwait goes
via the libc forwarding mechanism so presumably
pthread_cond_timedwaitonclock_np should do too. I'm working on that now.)

Thanks.

Mike.