OSDN Git Service

nptl: fix libc internal, dynamically enabled locking
authorTimo Teräs <timo.teras@iki.fi>
Thu, 22 Apr 2010 11:06:41 +0000 (11:06 +0000)
committerAustin Foxley <austinf@cetoncorp.com>
Thu, 22 Apr 2010 15:54:10 +0000 (08:54 -0700)
commit279c728ee62e53eb055227695bc6fafb31a3a5f1
treed7ceb8ed28bec1266dfcfac8af1501948b8f9bda
parentb93b98daf0dd45ac52f99fc4d906e5926cdd5239
nptl: fix libc internal, dynamically enabled locking

Final iteration to fix libc internal locking if libpthread is pulled
in by dlopen call (directly or indirectly).

We cannot really use the weak symbol trick for shared build, since
the symbols won't get refreshed if libpthread is pulled in dynamically.
In glibc, they have #ifdef SHARED magic to either use pthread_functions
table, or weaks. But as we shared object files with both builds, this
does not sounds good either.

The reintroduces the libc weaks.c, but uses them now only with static
build. For dynamic build, we still use the symbols with same name, but
provide weaks in forward.c so they end up dereferencing the
pthread_functions table indirectly if we are not linked to libpthread.
Mutex initialization is hard coded as inline, as it needs to happen even
if libpthread is not initially loaded.

Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Austin Foxley <austinf@cetoncorp.com>
libc/misc/pthread/Makefile.in
libc/misc/pthread/weaks.c [new file with mode: 0644]
libc/sysdeps/linux/common/bits/uClibc_mutex.h
libpthread/nptl/forward.c