nptl: mark symbols with libc forwarder hidden

Joakim Tjernlund joakim.tjernlund at transmode.se
Fri Apr 16 07:45:19 UTC 2010


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

Is this a big problem? To me this looks like an error in the app and the
link order should be fixed there.

> (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.

I don't think ld.so supports PROTECTED syms yet(unless someone added these lately)
Shouldn't be too hard to add I guess.

    Jocke



More information about the uClibc mailing list