Fix cinaps on arm32

[emillon]

Closes #4069

When dynlink:false is passed, the ARM backend emits MOVW/MOVT instructions which have relocations incompatible with PIC code.

This is similar to #2527 (ocaml issue: ocaml/ocaml#8867).

[emillon]

The fix is just for cinaps but it looks like all places that pass dynlink:false to Compilation_context.create might be affected, for example inline tests.

#2527 has a discussion about whether to pass -nodynlink or not:

• nodynlink prevents creation of PIE executables
• most distributions are moving to PIE (for security reasons)
• the optimisation to use dynlink only if necessary is "commented out" (true || ...) in normal executables:
  

  dune/src/dune_rules/exe_rules.ml

  Lines 132 to 139 in bbbbc67

  	let dynlink =
  	(* See https://github.com/ocaml/dune/issues/2527 *)
  	true
  	|| Dune_file.Executables.Link_mode.Map.existsi exes.modes
  	~f:(fun mode _loc ->
  	match mode with
  	| Other { kind = Shared_object; _ } -> true
  	| _ -> false)

So I think it's worth wondering if we should just remove this mechanism (and the ~dynlink argument) and never pass -nodynlink. One thing I'm not completely sure is how it interacts with the possibility of creating static executables, but I believe this works at the moment even with this bypassed optimisation. Thoughts @jeremiedimino ?

This part would be done in a separate PR of course, this one is enough to fix the cinaps issue.

[rgrinberg]

Yes, let's just disable this option everywhere until it's fixed with PIE. If you want to future proof things, you can add this value for dynlink:

type dynlink =
  | Enable
  | Disable_if_possible

This way we'll just need to update Disable_if_possible whenever OCaml fixes this option.

[rgrinberg]

Actually, I'm not sure if nodynlink is ever going to be fixed. So perhaps we should just get rid of it and re-evaluate later.

[emillon]

@rgrinberg I've just opened #4085 which removes the -nodynlink handling. It supersedes this PR but in terms of release engineering we can merge this (#4081) first so that it is backported more easily to a point release on 2.7.x.

[ghost]

I know that at Jane Street we have been using -nodynlink historically because it provided a noticeable speedup. I don't have up to date numbers so the speedup might be less now. Never passing -nodynlink by default seems fine, but it might be worth adding a workspace option to allow passing -nodynlink when possible (i.e. as we do now), for people who want the extra speedup.

[emillon]

We don't do any optimization for normal executables (the ones produced by executable stanzas) at the moment - the piece of code linked in #4081 (comment) is equivalent to let dynlink = true. So removing that support does not change how dune links executables.

Do you mean adding a way to remove the true || part?

[ghost]

Indeed, I forgot about this. Never-mind then. We might indeed want to allow this optimisation at Jane Street in the future, but we can cross that bridge when we come to it. In the meantime #4805 seems good.

[emillon]

Thanks! I just merged it to master. This one might be useful if we cut a 2.7.x point release but I'm closing it in the meantime.

[rgrinberg]

I created #4095 to track this.