Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006167OCamlOCaml backend (code generation)public2013-09-10 16:202015-01-24 17:36
Reporterpgj 
Assigned Togasche 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version4.01.0+beta/+rc 
Target VersionFixed in Version4.03.0+dev 
Summary0006167: OCAMLPARAM Support for Disabling Position-Independent Code (PIC) Generation
DescriptionAdd 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 [1] 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 `pic_code` variable to the `Clflags` module for both the AMD64 and the ARM native code generator backends, while it retains the default settings for both. I have tested it on FreeBSD/amd64, but it should work on the ARM platform and on other operating systems.


[1] http://openmirage.org/ [^]
Tagsjunior_job, patch
Attached Filesdiff file icon nopic.diff [^] (8,737 bytes) 2013-09-10 16:20 [Show Content]
diff file icon ocamlparam_pic.diff [^] (7,627 bytes) 2015-01-17 11:01 [Show Content]

- Relationships

-  Notes
(0011174)
doligez (administrator)
2014-04-02 17:11

One small remark: if we add a "nopic" flag we should also add a "pic" flag for symmetry (and because all the hard work is already done).
(0012912)
whitequark (developer)
2014-12-21 14:19

Reminder sent to: gasche

@gasche, can you please take a look at the attached patch?
(0012913)
gasche (developer)
2014-12-21 16:07

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)
+ (* -fPIC (only true by default on amd64) *)

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.
(0012914)
pgj (reporter)
2014-12-21 17:26

Sorry, folks, I was busy with other stuff and I did not come to respond to the notes. I think you are right, and yes, I think I could adapt the patch according to the recommendations.
(0012915)
gasche (developer)
2014-12-21 17:39

Nice! I certainly implied no criticism of you, I find it natural to could drift a bit after 6 months with no reply. You can take your time to prepare a patch.
(0012916)
pgj (reporter)
2014-12-21 17:48
edited on: 2014-12-21 17:48

Sure, no problem. Thanks for reminding me :-) I did not have time for the original project either (for which the patch was originally written) so it simply got slipped, indeed.

(0013134)
pgj (reporter)
2015-01-17 11:03

Please find a revisited version attached. It is now adapted to the trunk version as of today and theoretically has also the requested changes. I tested it on FreeBSD/amd64, it builds and works for me. Sorry for the delay :-)
(0013169)
gasche (developer)
2015-01-24 17:35

Merged in trunk, thanks!

- Issue History
Date Modified Username Field Change
2013-09-10 16:20 pgj New Issue
2013-09-10 16:20 pgj File Added: nopic.diff
2013-09-11 22:07 doligez Tag Attached: patch
2014-04-02 17:09 doligez Status new => confirmed
2014-04-02 17:09 doligez Target Version => 4.02.0+dev
2014-04-02 17:11 doligez Note Added: 0011174
2014-08-21 12:02 doligez Target Version 4.02.0+dev =>
2014-12-21 14:19 whitequark Note Added: 0012912
2014-12-21 16:07 gasche Note Added: 0012913
2014-12-21 16:07 gasche Tag Attached: junior_job
2014-12-21 17:26 pgj Note Added: 0012914
2014-12-21 17:39 gasche Note Added: 0012915
2014-12-21 17:48 pgj Note Added: 0012916
2014-12-21 17:48 pgj Note Edited: 0012916 View Revisions
2015-01-17 11:01 pgj File Added: ocamlparam_pic.diff
2015-01-17 11:03 pgj Note Added: 0013134
2015-01-24 17:35 gasche Note Added: 0013169
2015-01-24 17:36 gasche Status confirmed => resolved
2015-01-24 17:36 gasche Fixed in Version => 4.03.0+dev
2015-01-24 17:36 gasche Resolution open => fixed
2015-01-24 17:36 gasche Assigned To => gasche


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker