Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
OCAMLPARAM Support for Disabling Position-Independent Code (PIC) Generation #6167
Original bug ID: 6167
Add support for disabling Position-Independent Code (PIC) generation through the OCAMLPARAM environment variable. This change would make it possible to specify a "nopic" token which, when set, instructs the native code generator to emit position-dependent code independently of what was requested at the command line.
The rationale of this option is similar to the other flags already supported by OCAMLPARAM: Allow the user to force generation of position-dependent code without the need for modifying build system files or sources.
This patch was directly motivated by the need for making cross-compilation possible of the Mirage unikernel  to the "kFreeBSD" backend. This backend basically compiles Mirage (OCaml) programs into FreeBSD kernel modules, where certain expectations must be satisfied. One of those expectations is that the generated code must not be position-independent as the FreeBSD kernel dynamic loader (kld(4)) does not support ELF relocations of that type. Hence PIC generation has to be disabled globally for all the compiled code, regardless what the original upstream packages were instructed for. The "nodynlink" flag is also used in this case.
The attached patch implements this functionality by moving the
Comment author: @gasche
It would be more natural, I think, to use pic=0 and pic=1 to disable or disable position-independent code. Given the fact that the key-value-handling logic is already present in the OCAMLPARAM code, the current patch allows nopic=1 and nopic=0 to respectively disable and enable position-independent code (with "nopic" being a shortcut for "nopic=1"), which is a rather obscure interface. If people prefer using "nopic" to "pic=0", we could at least support both pic and nopic as keys as Damien suggests.
The other issue I have with the patch is the default-setting logic:
+let pic_code = ref (String.compare "amd64" Config.architecture == 0)
if you allow me to nitpick (no pun intended), this code would not scale to the addition of other architectures. We should pattern-match on Config.architecture, with at least a case for each architecture on which the option makes sense (having a catch-all pattern with the default value for the others is reasonable).
Is anyone willing to improve the patch on these two aspects? Given the non-stellar reaction time, I would assume that the original contributor pgj may not be willing to do the extra work. If nobody comes forward by the time of the release, I could do it myself.