Hi Richard,
Thanks for the work you have done. I would be happy to help on whatever
I can. I think that if you describe the steps to reproduce the issue on
bugz #826649 it would be a good start point for me to jump in.
Also, do you hang out on freenode? I'm always on channel #fedora-ppc.
[]'s
Gustavo
On 05/30/2012 02:19 PM, Richard W.M. Jones wrote:
I just spent a couple of days studying and attempting to fix ppc64
support in the ocaml package.
Background information
----------------------
OCaml is a nice, fast functional language. We carry ~ 70 OCaml-
related packages in Fedora. Since OCaml compiles to native code, it
needs a specific backend to be written for each target. Without this
it falls back to using a bytecode interpreter which is ~10 times
slower, so the backend is not required, but highly desirable.
Native code backends are not large nor especially hard to write. The
ppc64 backend in Fedora has just under 2000 lines of code. Moreover a
lot of that code is identical to the ppc (32 bit) backend.
486 asmrun/power64-elf.S
83 asmcomp/power64/arch.ml
989 asmcomp/power64/emit.mlp
241 asmcomp/power64/proc.ml
18 asmcomp/power64/reload.ml
65 asmcomp/power64/scheduling.ml
103 asmcomp/power64/selection.ml
1985 total
Upstream, there are backends for many different architectures. Of
interest to this list, there is a backend for ppc (32 bit), and ppc64.
*However* the upstream ppc64 backend ONLY works on Mac OS X, because
it makes assumptions[1] about the architecture and the assembler which
don't work with GNU as.
A long time ago, David Woodhouse wrote or modified a ppc64 backend,
which we are now carrying as a separate, non-upstream patch in Fedora.
It generally works, although it has several bugs, of which more later.
Upstream rejected this backend because they don't have the hardware
required to maintain it.
What I did
----------
Because the ppc64 backend is so hard to maintain as a patch, I broke
it out into a git repository. This also makes maintaining other
patches easier (in particular my backport of the new ARM code
generator). If you need access to this, please request it in the
usual way via fedorahosted:
http://git.fedorahosted.org/git/?p=fedora-ocaml.git
After doing this, I rewrote parts of our ppc64 backend so that they
more closely match the upstream ppc backend, ie. so that the
differences in the following commands are minimized as far as
possible:
diff -urb asmcomp/power64 asmcomp/power | less
diff -urb asmrun/power64-elf.S asmrun/power-elf.S | less
Note that I did NOT make any functional changes to the ppc64 backend
when doing this.
I also compiled a number of packages using our ppc64 backend. I
noticed that ocaml-camomile wouldn't compile. One module of this
program contains a very large "entry" function. The "entry"
function
of a module is the name given to all the toplevel code in a module
which runs when the module loads and isn't a part of any function
definition in the module. By experimentation I found that when the
entry function exceeds around 26 kbytes, it causes corruption of the
minor heap. This is some sort of bug in the code generator, but I
wasn't able to determine what, and would appreciate any help in
finding it:
https://bugzilla.redhat.com/show_bug.cgi?id=826649
I also found a variety of other bugs which all seem to be caused by
the smaller available default stack on ppc64 combined with the larger
number of registers (therefore more stack spillage). I will report
these upstream as I come across them, but the most serious is this
one:
http://caml.inria.fr/mantis/view.php?id=5368
How I need help
---------------
I could do with help on #826649, particularly from ppc64 codegen
experts. Also on compiling any remaining ocaml-* packages on ppc64
(most already done) and checking that they actually function. Also on
identifying any remaining ocaml packages that have ExcludeArch: ppc64,
removing that and if necessary fixing any bugs found.
Rich.
[1] I'm not precisely sure what assumptions it's making, and I could
be wrong on this point, but I certainly couldn't get the upstream
ppc64 backend to work on Fedora16/ppc64, and I also noticed the
assembler syntax is somewhat different from gas and incompatible.