libpthread vs libc dynamic link order

Bernd Schmidt bernds_cb1 at t-online.de
Thu Jun 21 14:24:52 UTC 2007


In uClibc (when using linuxthreads.old), libc.so and libpthread.so both 
contain some functions with the same name, e.g. 
_pthread_cleanup_push_defer.  The version in libc tries to forward the 
call to a function found in a table called __libc_pthread_functions in 
libpthread.  This table is initialized from an array called 
__pthread_functions in pthread.c; this array contains a reference to 
_pthread_cleanup_push_defer.

Depending on the order in which the dynamic linker sees libc.so and 
libpthread.so, this table in libpthread can refer to either the function 
in libc or the one in libpthread.  We observed this with a Qt example 
program: the executable was linked against libQtNetwork, which in turn 
was linked against libpthread, but the executable itself did not 
reference libpthread.so.  As a result, the dynamic linker ended up with 
an order where it picked the functions in libc.so over the ones in 
libpthread.so, and when the forwarder function in libc is called, it 
keeps looking up itself in the table, and calling itself.

Is there a reason the forwarding functions in libc are visible to other 
shared libraries - it seems to me they are just for libc internal use? 
If not, the patch below seems to fix the problem here.  Any other ideas?


Bernd

-- 
This footer brought to you by insane German lawmakers.
Analog Devices GmbH      Wilhelm-Wagenfeld-Str. 6      80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: hidden-forward.diff
Url: http://lists.busybox.net/pipermail/uclibc/attachments/20070621/a4438962/attachment-0002.diff 


More information about the uClibc mailing list