NPTL MIPS, current git head, programs block on startup

Carmelo AMOROSO carmelo.amoroso at st.com
Tue Apr 27 16:13:03 UTC 2010


On 4/27/2010 1:09 PM, Timo Teräs wrote:
> Andreas Schultz wrote:
>> 2010/4/27 Timo Teräs <timo.teras at iki.fi>:
>>> Andreas Schultz wrote:
>>>> 2010/4/27 Timo Teräs <timo.teras at iki.fi>:
>>>>> 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
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
> 



More information about the uClibc mailing list