Re: [PATCH] Provide pthread_atfork in libc_nonshared.a and libc.a.

[Rich Felker <dalias at aerifal dot cx>]

On Thu, Oct 03, 2013 at 07:29:10AM +0200, Jakub Jelinek wrote:
> On Wed, Oct 02, 2013 at 09:30:34PM -0400, Carlos O'Donell wrote:
> > Aside from the objections that Rich raised, which are
> > general objections to the weakref-and-check idiom that
> > doesn't work with static linking.
> 
> Note that the weakref-and-check idiom works just fine if the symbol checked
> is the same as the one you would use, that should work just fine with static

No, it doesn't. For instance, take pthread_mutex_lock. You cannot use
the presence of pthread_mutex_lock (as determined by the
weak-referenced symbol being non-NULL) to determine whether you need
to call pthread_mutex_lock. It's possible that the program is
multi-threaded, but has no other use of locking outside of your
library code, and in this case you would wrongly determine that you
don't need locking for accessing your own global state.

> pthread_mutex_{,un}lock aren't good examples, because they are stubbed in
> libc.so.6 already, but if they weren't, using weak on both the symbols
> and if (pthread_mutex_lock) pthread_mutex_lock (&lock); else dummy_lock (&lock);
> and if (pthread_mutex_unlock) pthread_mutex_unlock (&lock); else dummy_unlock (&lock);
> would be problematic with static linking too - if pthread_mutex_lock was
> linked in and pthread_mutex_unlock would not, you'd end up locking but not
> really ever unlocking.  Which is why in some cases you need the same guard.
> Even if the guard checks all the relevant symbols together (costly at
> runtime and for relocations), the thing is that usually you want to support
> threading whenever pthread_create got linked in, and pthread_create could be
> linked in, but others could not during static linking.

Right.

> So, to make this work reliably with static linking (but, why is static
> linking important when it hasn't been for many years before?), we'd need
> some ELF extension, where the user of these weak refs could express the
> requirement in the objects in some way, if symbol A is defined, then
> make sure symbols B, C, D, E are defined too (force treating them as
> non-weak refs).  Could be perhaps some note section, used by the linker and
> discarded from binaries or shared libraries.

The weak references are just wrong. Instead, the library should have
strong references to symbols with weak _definitions_ in either (a
hypothetical dependency) libpthread_stubs.so or libc.so that do
nothing, and that get overridden by the strong definitions in
libpthread.so. Or we could just do away with the silliness of having
these functions in a separate .so file, make libpthread.so a stub, and
put everything in libc.so. For this to work for glibc, though, a lot
of mess with symbol versioning would be needed. In musl, it was easy.

Rich