Hide Forgot
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...
Created attachment 154225 [details] test case
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.
Created attachment 154232 [details] parser.s
Created attachment 154233 [details] pervasives.s
So, if we fix the code in asmcomp/power64/ to use the TOC properly instead of absolute references, the linker strangeness is expected to go away?
The original linker bug is now fixed upstream, do you still need it in F7 or can it wait for F8?
Er, I don't think I need it in F7; thanks. I interpreted it as a 'don't do that then' and we're working on fixing the ML compiler to use the TOC instead.
Yeah, your interpretation was certainly correct, nevertheless there was a linker bug which I fixed. Closing as UPSTREAM.