pthread_atfork on ppc64

Ryan S. Arnold ryan.arnold at gmail.com
Mon Jun 4 21:36:18 UTC 2012


On Mon, Jun 4, 2012 at 2:20 PM, Steven Munroe
<munroesj at linux.vnet.ibm.com> wrote:
> On Sat, 2012-06-02 at 12:39 +0100, Richard W.M. Jones wrote:
>> As explained at length here:
>>
>> http://ryanarn.blogspot.co.uk/2011/07/curious-case-of-pthreadatfork-on.html
>>
>> on ppc64, 'pthread_atfork' is in a separate static library called
>> libpthread_nonshared.a, and libpthread.so is a linker script that
>> links both libpthread.so.0 (dynamically) and libpthread_nonshared.a
>> (statically).
>>
>
> Well Ryan is the current PPC platform maintainer in GLIBC so I will let
> him answer for himself. But as the previous platform maintainer, I can
> think of several good reasons to do this, ie to avoid nasty deadlocks
> between fork/at_fork and the ld64.so PLT resolver.

Hi Richard,

You stated in the original email that this works on x86_64 because
there's "an ordinary pthread_atfork symbol in the regular shared
library too."  Unfortunately, I think you're getting lucky in that
case and picking up the older symbol version.  Looking at an x86-64
fedora system I see the following:

objdump -x /lib/x86_64-linux-gnu/libpthread.so.0 | grep pthread_atfork

000000000000d450 l     F .text 000000000000001c
__dyn_pthread_atfork
000000000000d450 g     F .text 000000000000001c
pthread_atfork at GLIBC_2.2.5

Whereas, on ppc64 there is no pthread_atfork symbol in libpthread.so.0
at all, including the GLIBC 2.0 compat pthread_atfork.  This is
because PPC64 support wasn't available until GLIBC 2.3, which is after
pthread_atfork was migrated to libpthread_nonshared.a.

The current/latest version of pthread_atfork exists in
libpthread_nonshared.a for ALL platforms.  You can do an nm on
libpthread_nonshared.a and see this fact:

I haven't been around long enough to know WHY this was done but it
appears to have happened sometime in 2001.  I suspect it was done in
order to encode a DSO handle (version) in the register_atfork call.

My thought is that /usr/lib64/ocaml/stublibs/dllthreads.so should be
statically linked with libpthread_nonshared.a sometime when it's being
built.  I think simply linking with -lpthread _should_ work (but don't
use -static if you do this).

>
> Also note that the PPC64 Linux ABI is very different from both the PPC32
> ABI and the Darwin ABI. Assuming that they are the same or even similar
> will just lead to problems.
>
> So read up on
> http://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi-1.9.html

This is the latest 64-bit ABI.  It is a bit dated.

> which should help with important background info
>
> I have asked Ryan to provide URLs to other important material you might
> find useful.

This is the latest Power ISA:

https://www.power.org/resources/downloads/PowerISA_V2.06B_V2_PUBLIC.pdf

This is the latest 32-bit ABI:

https://www.power.org/resources/downloads/Power-Arch-32-bit-ABI-supp-1.0-Unified.pdf

The only thing not covered in the 32-bit ABI is the VSX facility.

Ryan S. Arnold


More information about the ppc mailing list