On 4/27/2010 1:09 PM, Timo Teräs wrote: > Andreas Schultz wrote: >> 2010/4/27 Timo Teräs <[email protected]>: >>> Andreas Schultz wrote: >>>> 2010/4/27 Timo Teräs <[email protected]>: >>>>> Andreas Schultz wrote: >>>> [...] >>>> >>>>> Uh. Is the application linked against libc before libpthread? >>>> The application is not directly linked against libpthread, but one of >>>> the other libraries pulls it in. >>> This has never worked on MIPS. Someone needs to implement the >>> protected symbol support for mips ld.so. >>> >>>>> Check with ldd the order of how libraries are pulled in. >>>>> >>>>>> Looking at init.c my best guess would be that >>>>>> .ptr__pthread_cleanup_push_defer should be initialized with >>>>>> __pthread_cleanup_push_defer and not with _pthread_cleanup_push_defer >>>>>> (two undelines instead of one). >>>>> It's because MIPS ld.so is not supporting protected symbols yet. >>>>> Mmm... Using the two underscore variant might help for immediate >>>>> problems, but other things will broken unless protected symbols >>>>> are implemented. >>>> The two underscore change alone is not sufficient, i have now managed >>>> to get it working with the attached patch. Everything seems to fine so >>>> far. >>> Forgot to attach the patch? >> >> ups, yes... > > This as such, will not fix all problems. All the symbols in the > forwarding table need special attention. Currently all those symbols > are marked with attribute_protected and it's expected that ld.so makes > sure the libc counter parts do not override the libpthread internals. > This currently works only on x86. >
what ? probably I did not understand very well the impact of your latest changes regarding protected symbols, it's a my fault, but we were too in hurry at the end to commit a change with a so huge impacts. So it seems that all previously working archs that were the first supporting NPTL (mips, sh, arm) are now broken... that sounds not a good thing !!! anyway, I'll check the current status on sh. >>> I learned the hard way that it's not easily doable without the >>> protected symbols. Otherwise you easily mess up one of the weird >>> linking scenarios or how libc-libpthread interacts. >> >> mhh, there seem to be lots of protected symbols.... :-( > > Yes. I recently added those. Each function in the struct you are > modifying is attribute_protected to make sure libpthread and libc > interact properly under various circumstances. > > We could get away from using protected symbols if we renamed all > those symbols to follow some rules. But attribute_hidden for easier > at the time for me. > > Basically, all libpthread exported function would need to have > internal libpthread used in the struct there, and then aliased to > the exported name. > > Looking at the code, some of the symbols are done like that: > - many pthread_* functions are referring to __pthread_* > - many __pthread_* functions are referring to __pthread_*_internal > > BUT, some are just referring to the symbol with same name. This > will break things without attribute_protected and ld.so support for > it. > > Sadly, this has never worked properly. I may have renamed the > two symbols involved for symmetry before fully understanding how > the beast worked. But now it gives a good indication that there's > a problem instead of breaking in subtle ways later. > > Also, using protected symbols is slightly better since it produces > smaller libraries. It generates less symbols. > >>>>> Changing linking order of application to pull in libpthread first >>>>> should fix it too. >>>> I'll try that... >>> Hacky solution for you is to add -lpthread for your main application. >>> Proper solution is protected symbol support in ld.so. > > Does linking the main binary to -lpthread fix the problem? > _______________________________________________ > uClibc mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/uclibc > _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
