See attached tarball. There is caml_alloc() function, provided by asmrun/alloc.c.
The caml_alloc() function is in stdlib/libasmrun.a, which is linked into the
executable. There is no other caml_alloc.
So why is caml_alloc in BSS in the output? And why are we just jumping to it...
Starting program: /home/dwmw2/bz/ocamlopt.opt
Program received signal SIGSEGV, Segmentation fault.
0x0000000010208bd0 in caml_alloc ()
(gdb) x/10i $pc
0x10208bd0 <caml_alloc>: .long 0x0
0x10208bd4 <caml_alloc+4>: .long 0x0
0x10208bd8 <caml_alloc+8>: .long 0x0
0x10208bdc <caml_alloc+12>: .long 0x0
The actual patches we have to attempt to get ocaml to build on ppc64 are
available elsewhere; when we understand why this linker strangeness is happening
we can make some more progress...

Can I see assembly for stdlib.a's pervasives.s and parsing/parser.s?
To me this looks like the compiler is either not ported to ppc64 at all
or extremely badly. ppc64 code shouldn't be using R_PPC64_ADDR16_{HA,HI,LO}
relocations at all, ppc64 code is supposed to be position independent always
and is supposed to use TOC and access to TOC, while this CAML stuff uses
heavily these normally ppc32 relocations for non-pic code, which e.g. assume
code in low 2 resp. 4GB of address space, etc.
The reason why caml_alloc and caml_sys_exit end up in .dynbss section
is exactly this, there are non-got references to it and the linker never handled
that well, as it is never produced in ppc64 code.

The compiler is indeed not ported to ppc64 very well -- we're working on that.
The patch at http://dev.nigelj.com/ocaml-3.09.3.ppc64.patch was Nigel's start,
based on existing Rhapsody PPC64 code. The first SEGV was when caml_c_call()
jumped into the function descriptor -- after fixing that (with a quick hack
which doesn't load the TOC pointer yet), the next SEGV was caml_alloc_array()
jumping into BSS when it should have been calling caml_alloc(). At which point I
got confused.