This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
linking too.  What is problematic, but unfortunately often unavoidable, is
using one symbol in the check and other (or multiple) in the code guarded
by that check, because with static linking you could end up with the checked
symbol being defined, but the assumed ones not being included.

pthread_mutex_{,un}lock aren't good examples, because they are stubbed in 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.

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 root cause that prompted this fix is that libselinux
> has a need to use pthread_atfork and not require libpthread.
> Given that pthread_atfork is a wrapper around __register_atfork
> it seemed a natural fix to provide pthread_atfork in libc.a
> and libc_nonshared.a.

I support this, but as I'm the one that suggested that, it probably doesn't
count ;).


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]