On Mon, Jun 4, 2012 at 2:20 PM, Steven Munroe
<munroesj(a)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(a)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-...
The only thing not covered in the 32-bit ABI is the VSX facility.
Ryan S. Arnold