nptl: mark symbols with libc forwarder hidden

[Timo Teräs]

Austin Foxley wrote:
> On 04/14/2010 10:01 AM, Timo Teräs wrote:
>> Add attribute_hidden to all symbols having libc forwarder. This prevents
>> recursive self calls which would happen if libc is before libpthread in
>> linking order: the forwarder functions would call itself via the function
>> table, since the libpthread symbols would get overwritten with libc ones.
>> This has not been a problem in glibc since there these symbols are marked
>> hidden with linker version-script. Since we don't use one, we need to mark
>> these explicitly.
>>
>> Signed-off-by: Timo Teräs <timo.teras at iki.fi>
> 
> This looks like what we want. I'll apply this.

Hum. Actually looks like this is not right either. It appears that there's
several different ways how the pthreads mutexes are called from libc.

Previously uclibc had these:
 1. internal libc locking:
	seems to resolve to use the internal __pthread_mutex_*
	weaks defined for__pthread_* in libc/misc/pthread/weaks.c to give
	dummy functions if linked statically or without libpthread
 2. pthread_* forwarding for applications
	so single/multithread libs can link to basic pthreads stuff without
	libpthread; it uses the pthread_functions forwarding stubs in thread
	implementation specific forwarders.c
 3. stdio locking
	that uses futexes (from nptl headers), or revers to #1 style locking

However, (1) will never work properly. The reason is that weak vs. strong
aliases are not resolved dynamically. If ld.so picks the weak definition from
libc first (e.g. -lc before -lpthread), you end up using the libc version.
(Only glibc ever had dynamic weak resolution, meaning strong alias from later
 library would override weak alias; but this behaviour was reverted as it
 was considered bad. It's still doable by setting LD_DYNAMIC_WEAK=1).

Now, glibc seems to do (1) as follows:
 1. define *protected* versions of __pthread_* from libpthread, so libpthread
    will use them always, but also exports (at least subset of them)
 2. libc has *weak definition in headers* of __pthread_* causing the
    references to be weak, and linking succeed even if __pthread_* symbols
    are not present
 3. it uses __libc_maybe_call to first check if the function symbol is null,
    and if not then calls it

I think we should the same as glibc, by converting uClibc_mutex.h to use
libc-lock.h from threading implementation.

Sounds reasonable?