various nptl patches

Timo Teräs timo.teras at iki.fi
Sat Apr 17 10:32:27 UTC 2010


Timo Teräs wrote:
> The whole __GI_ aliasing thingy on libc side is a bit weird still.
> I wonder if we could remove all that and just use the proper
> visibility attributes. But I guess that's another story.
> 
> Oh well. At least nptl on x86 is starting to get to usable state
> now. There will be still problems application without libpthread
> goes and dlopen()'s a library loading libpthread. But that's
> easily "fixable" by just linking the main app to libpthread.

I was thinking about how glibc gets away with this. Apparently
libc-lock.h does some deep voodoo on what kind of locking primitives
it chooses for each library.

It looks like libc and libpthread end up always using the low level
lock stuff directly lll_*. And for the remaining libpthread entries
the libc ends up calling libpthread always via the ptf (the pthread
function pointers struct). Thus libc should not be using the weak
symbol magic at all. This seems to be the only way to make libc
call the actual libpthread functions if it's dlopen()'ed later.

Also, it would appear that libpthread needs additional fixing to
initialize itself in case it's dlopen loaded. I also remember there's
some ldso flags that make libpthread permanent so it won't get
unloaded when the last library requiring it gets dlclosed.

So I guess we need another stab on fixing libc-lock for uclibc.
I might take a look at this next week if there's nothing else
strange in the current tree.

The previous patches are still needed though. Otherwise the
main application can get wrong symbols depending on various things.
The protected patches especially are important as some of the
forwarding stubs have same name as the pthread implementation it
forwards to (the actual name used in ptf struct initialization).

This whole libc-libpthread interdependency and making libc run
without libpthread seems pretty complicated, and misunderstood
previously. Especially since the "normal symbol" vs. "weak symbol"
semantics have changed (do note: it seems that "strong symbol" as
concept seems to have been deprecated; apparently the consensus is
that even if it sounds good idea, it's bound to cause more confusion
and mistakes and non-consistent behaviour than solving problems).

I guess we need a document, or at least some comments on how all
this is supposed to be working.


More information about the uClibc mailing list