forward.c and libc-lock.h, __pthread_mutex_X usage

Peter S. Mazinger ps.m at gmx.net
Wed May 24 08:08:04 UTC 2006


Hello!

I have reviewed the new linuxthreads version and I have doubts how the 
__pthread_mutex_X() should work (lock,unlock,trylock,init).

Z=pthread_mutex_X

/*simplified forward.c*/
Z->__libc_pthread_functions.ptr_Z

strong_alias(Z,__Z) where __Z is hidden (at least in libc.so)

for ex.
__pthread_mutex_init in libc.so->(strong_alias, will this step work anytime?)->
pthread_mutex_init->(forward.c)->__libc_pthread_functions.ptr_pthread_functions.ptr_pthread_mutex_init->
(pthread.c)->depending on what we have in pthread.c either 
__pthread_mutex_init or pthread_mutex_init in libpthread.so

Now should the redirect end at the internal hidden __pthread_mutex_init or 
the visible pthread_mutex_init (pthread.c) or does it matter at all?

if files in libc.so were using libc-lock.h and would use __libc_*lock_*

/* simplified interpretation of libc-lock.h */
#if !defined NOT_IN_libc && defined SHARED /*all .oS in libc.so*/
Z->__libc_pthread_functions.ptr_Z
#else
Z->__Z
#endif
/* the above could be adapted to apply by some other logic to uClibc, 
making it independent of SHARED */

Why is libc-lock.h not used generally, only for iirc rpc?
This is probably historical, so please Erik/Manuel?

Thanks, Peter

-- 
Peter S. Mazinger <ps dot m at gmx dot net>           ID: 0xA5F059F2
Key fingerprint = 92A4 31E1 56BC 3D5A 2D08  BB6E C389 975E A5F0 59F2




More information about the uClibc mailing list