Re: Mirage/kFreeBSD Compiler Patches

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 3 Sep 2013, at 18:37, PALI Gabor Janos <pgj@xxxxxxx> wrote:

> 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).

Thanks for breaking these up Gabor!  I expect that a number of the patches
are generally relevant to other backends in the future, as we move to establish
the differences between many of the backends.

> 
> 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.)

It's probably best to disable this by default in ARM.  How about modifying
the Clflags to be either `True|`False|`Default, and then using that to decide
what the architecture-specific backend should be?

I expect that PIC code is a lot more expensive on ARM than it is on AMD64,
although it's worth verifying this with an upstream patch submission.

> 
> 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.

This one probably won't get merged, since 4.02 is moving out all the otherlibs
into separate packages that are outside the core distro.  This is good news for
your port anyway!  I'll dig out the Mantis upstream issue for this.

> 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.
> 

Looks good -- I agree with your assessment that this isn't mergeable until
we precisely define what sort of impact this will have, but the strategy of
"carefully avoid floating point or else crash" seems to be working well enough
for now.

Do you want to submit the nopic one upstream for now and start some discussion
going on that?

cheers
Anil