Mirage/kFreeBSD Compiler Patches

[PALI Gabor Janos <pgj@xxxxxxx>]

Hi there,

Anil requested me to show the OCaml compiler patches I am currently relying
on for the kFreeBSD backend -- in the hope that they could be merged into the
upstream and therefore making the work with this backend easier.  I have
recently updated the backend to use the 4.01.0beta1 version of the OCaml
compiler (and run-time system).

The patches are as follows, including some commentary:

Patch: 
https://github.com/pgj/ocaml/commit/e63fdcbad6b403a52a7458e849136b08f97bb3d3.patch
Synopsis: Add support for explicitly disabling PIC code generation to
          OCAMLPARAM.

Description:
The FreeBSD kernel does not support loading modules that contain symbols with
certain ELF relocation types that would allow the OCaml compiler to emit
position-independent code, e.g. R_X86_64_GOTPCREL, R_X86_32, and
R_X86_64_PLT32.  Hence this must be disabled with the -fno-PIC flag when
targeting applications for the Mirage/kFreeBSD backend.

However, this is turned on by default, so it would be required to modify all
the build files for all the dependant OPAM packages to include this setting.
Fortunately, OCaml 4.01 introduces a new environment variable, OCAMLPARAM,
whose value is parsed for environment compiler settings, and therefore it
makes possible to turn PIC generation off, independently of what was
requested at invocation.

Here, this feature has been extended with an additional option, "nopic" which
turns PIC generation off by default on amd64 (and arm) platforms.

Mergeable: Probably yes, harmless by default.  Albeit it may change the
default behavior of emitting PIC on arm.  (The arm port does not seem to
have PIC on by default, but supports it.)


Patch: 
https://github.com/pgj/ocaml/commit/2e155b0c4e551f3cfb31aedbe44b4304ad2e4ccf.patch
Synopis: Allow extra libraries to be cleaned/installed separately.

Description:
This is only a minor technical addition to the compiler's Makefile which
makes possible to reinstall the standard compiler libraries without reinstall
all the compiler files.

This is used with the previous patch primarily, when the compiler libraries
have to be built without PIC.  However, for the Mirage/kFreeBSD
(cross-)compiler, first I build and install the regular compiler to have all
the dynamically-linked version of those libraries and a working version of
Camlp4.  Technically, in this order:

- Build & install the compiler, with PIC, Camlp4, and shared libraries.
- Rebuild & reinstall the stdlib without PIC.
- Rebuild & reinstall the "otherlibs" (bigarray, str, etc.) without PIC.
- Remove the module for Dynlink to disable building packages with shared
  libraries (as some build systems check for this).

This procedure is required because some of packages have certain implicit
expectations from the installed compiler, such as presence of shared
libraries (even if the package itself will not use them at the end).

Mergeable: Yes.


Patch: 
https://github.com/pgj/ocaml/commit/26196344b32a1bb243b0e8986e5c0c82b05cc262.patch
Synopsis: Add fixed-point arithmetic support for doubles, unroll
          floating-point primops.

Description:
This change introduces another OCAMLPARAM option, "fixedpt" which can tell
the OCaml compiler to generate (64-bit) floating-point constants with
fixed-point representation.  The value of "fixedpt" can tell how many bits are
reserved for the fractional part.  This is not used when building the
cross-compiler, it is only used when the building a Mirage applications.  That
is, the compiler itself always uses the standard OCaml run-time and
floating-point numbers, while the built kernel modules always use their
fixed-point counterparts.

Note that, in order to let these approaches to share the same API, I also had
to "unroll" the primitive floating-point operations into regular C function
calls in the native code generator.  This will probably make the
floating-point-based computations slower and, due to that the fixed-point
numbers currently store the fractional part in 16 bits, leads to loss in
precision.

Mergeable: No.  At least not this version.


Feel free to ask if I was unclear regarding something... :-)