static linking for pthreads in nptl branch?

[Chris Metcalf]

On 9/2/2008 10:25 AM, Chris Metcalf wrote:
> On 9/2/2008 10:06 AM, Carmelo AMOROSO wrote:
>   
>> I had to read it more carefully.. you are right, and yes, probably the
>> issue you were referring to about static link and pthread was raised
>> by me in the past.
>> It was related to opendir function that is the only function within libc
>> that calls pthread_mutex_init, and yes, when statically linked, even
>> if using -lpthread, it was bind to the libc stub. At that time I fixed
>> opendir by adding a memset to clear the lock data.
>> (see http://www.uclibc.org/cgi-bin/viewcvs.cgi?rev=20625&view=rev)
>>     
>
> Since I just made that example up, it's funny that it was a real problem :-)
>
>   
>> What about adding PTHREAD_STATIC_FN_REQUIRE (pthread_mutex_init)
>> in nptl/init.c ? were you thinking to this with the word 'register'.
>> I did not test it, but it may be sufficient.
>>     
>
> I had been thinking of just using the same shared model of "struct
> pthread_functions", but that's probably overkill, since it would bring
> in all of libpthread.a even if the application only used a few
> functions.  So perhaps just the extra PTHREAD_STATIC_FN_REQUIRE is the
> right approach.  It also avoids the scary assumption that
> PTHREAD_MUTEX_INITIALIZER is also all-zeroes on all platforms.
>   

I think we also need to add

/* Used by __UCLIBC_MUTEX_LOCK for the libc locking code. */
PTHREAD_STATIC_FN_REQUIRE (_pthread_cleanup_pop_restore)
PTHREAD_STATIC_FN_REQUIRE (_pthread_cleanup_push_defer)

in pthread_create.c to avoid getting the stub versions.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com