NPTL MIPS, current git head, programs block on startup

[Timo Teräs]

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.

>> 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?