static linking for pthreads in nptl branch?

[Chris Metcalf]

On 9/1/2008 11:29 AM, Carmelo Amoroso wrote:
> Chris Metcalf wrote:
>> It looks like my real problem was specific to some changes I made in our
>> malloc.  We use the "mspace" malloc that is in later versions of Doug
>> Lea's malloc, and one thing we do for performance is to give each thread
>> its own mspace arena for allocation.  To make this fast for
>> single-threaded programs we have a stub pthread_mspace() routine in libc
>> and the real one in libpthread.  But if it's only referenced from libc
>> (from malloc), then when a static link is done, we end up getting the
>> single-threaded version from libc instead of the multi-threaded version
>> in libpthread.  (Of course it works fine with shared objects.)
>>
>> For now I'm fixing this by adding a dummy reference to pthread_mspace
>> from nptl/init.c so it always gets resolved early enough in the static
>> link process.  It seems like any pthread symbols not explicitly
>> mentioned in nptl/pthread_create.c would have this problem too, though:
>> for example, if you had a function in libc that wanted to be thread-safe
>> when linked with -pthread and so called pthread_mutex_init() to set up a
>> mutex in malloc'ed memory (for example), it would actually end up
>> getting the libc version of pthread_mutex_init() when linked
>> statically.  The libpthread versions of pthread_mutex_lock() and unlock
>> are linked in properly since they're referenced in pthread_create().
>>
>> I suspect the solution to all of this is to make sure to always
>> "register" the correct function pointers for the whole API when
>> libpthread's initialization code is called, so that the libc versions
>> always end up doing a lookup on the registered function pointer and
>> calling that, even with static linking.
>>
>
>
> I understand your point, but can we say that we are building
> a multi-threaded application if we don't call pthread_create
> (that means linking pthread_create.o) ?

Sorry I wasn't clear.  Supposing we have a static library (or a function
in libc.a) that wants to be thread-safe if it's linked with pthread, and
still work if it's used in a single-thread program.  It calls
pthread_mutex_init().  The main program does call pthread_create(), so
when we link statically we do get a bunch of non-stub pthread functions
-- but not pthread_mutex_init(), which we still get the stub for (unless
the main program also called it).  Oops!  :-)

> I think that you should define your stub for mspace as weak,
> and, for the static case, call it by guarding against NULL...
> if I've understood it correctly.

I don't think weak will help in this case.  The weak undef will still
just bind to the libc version, even if it's a weak def and the
libpthread one is strong.

Thanks!

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