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
Index: forward.c
===================================================================
--- forward.c (revision 1667)
+++ forward.c (working copy)
@@ -31,7 +31,7 @@ struct pthread_functions __libc_pthread_
# define FORWARD2(name, rettype, decl, params, defaction) \
-rettype
\
+rettype attribute_hidden \
name decl \
{ \
if (__libc_pthread_functions.ptr_##name == NULL) \
_______________________________________________
uClibc mailing list
[email protected]
http://busybox.net/cgi-bin/mailman/listinfo/uclibc
