I'm puzzled by something I'm seeing, and wondering if the simple fix is wrong. I'm using the uClibc-nptl branch as of change 22990.
The scenario is that a user links "-lc -pthread", and thus symbols are resolved from libc before libpthread. (A similar scenario is that a user links with only "-lrt", for example, and thus gets "-lrt -lc" from the linker, and the loader brings in libpthread afterwards to resolve the dependency from librt.) Now this is meant to be handled by the whole forwarding dance. libc links in forward.c from libpthread/nptl to define, e.g., __pthread_mutex_lock(), which checks a structure full of pointers, each one pointing either to the "real" function, or NULL, so the forwarding function can either forward properly, or else return a dummy value. When libpthread initializes, __pthread_initialize_minimal_internal() copies a structure full of "real" function pointers into libc's structure. But where this seems to go off the rails is that libpthread's structure is full of pointers to __pthread_mutex_lock (etc.), which the loader simply resolves to the first such symbol in the search path, namely... the forwarding version in libc. So that function ends up calling itself in a loop forever. One "obvious" solution would be to use -Bsymbolic. This will bind the references from within libpthread to libpthread symbols directly, without using the loader to look them up. Unfortunately this will break references to global data like stdin, optind, etc., so is probably not an option. However, it seems like we should be able to use the libc_hidden_def mechanism on the libpthread side to define and reference these variables. That will give us "-Bsymbolic" semantics for those functions from within libpthread, but still allow libc to call directly to them when things are linked normally with "-lpthread -lc". I'll go ahead and implement and test this solution. Perhaps the tool chain on my architecture is broken, and most folks normally get the "right" behavior by default somehow? I suspect I'm confused. :-) -- Chris Metcalf, Tilera Corp. http://www.tilera.com _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
