nptl: mark symbols with libc forwarder hidden

[Joakim Tjernlund]

Timo Teräs <timo.teras at gmail.com> wrote on 2010/04/16 10:00:59:
>
> Joakim Tjernlund wrote:
> >> Austin Foxley wrote:
> >>> On 04/14/2010 10:01 AM, Timo Teräs wrote:
> >> 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.
>
> It just isn't possible always easily.
That can't be a big deal, feels like a bug in the app that should/could be
fixed.

> This also hits the case if libpthread
> gets pulled in by dependency library and not by the main app.
But this is a bigger concern. Is this supposed to work or is it an glibc
extension?

>
> >> (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.
>
> Isn't protected: define symbol as global, but generate "local"
> non-overridable relocations. Thus it's just code generation change
> compared to hidden visibility. Not entirely sure about this, though.
> But I think it should just work.

Ah, like LD option -Bsymbolic does? That is library wide so one has to find
some __attribute__ that operates on a single symbol.

     Jocke