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 _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
