Ocamldebug support broken in 3.6

[jserot]

When launching ocamldebug on a bytecode executable generated with dune(v 3.6), the directory variable, used to search for source files is no longer set correctly:

Example:

	OCaml Debugger version 5.0.0

(ocd) break @ Main 2
Loading program... done.
No source file for Main.
(ocd) directory
Reinitialize directory list ? (y or n) n
Directories:  . /Users/xxx/.opam/5.0.0/lib/ocaml
  /Users/xxx/.opam/5.0.0/.opam-switch/build/ocaml-base-compiler.5.0.0/stdlib
  /Users/xxx/.opam/5.0.0/lib/ocaml /workspace_root /workspace_root/example
  /workspace_root/example/.main.eobjs/byte /workspace_root/src/lib
  /workspace_root/src/lib/.foo.objs/byte

The dune variable workspace_root has not been resolved.

Things were ok when using dune 2.6.

OCaml 5.0, dune 3.6

[richardlford]

The code that is causing this problem is in src/dune_engine/action_exec.ml. The mapping is taking place on lines 538-539 in the current sources which are:

              { source = Path.to_absolute_filename root
              ; target = "/workspace_root" }

I don't know what other purposes this code has, but a workaround that lets ocamldebug work again is to replace this with:

              { source = Path.to_absolute_filename root
              ; target =  Path.to_absolute_filename root }

that is, make the mapping a NOP. If there are some cases where this mapping is desireable, then probably another fix is needed, but this workaround works for my current purposes. Perhaps doing this mapping should be under option or stanza control.

[jserot]

Thanks.
Should we put a PR for this ?

[richardlford]

I thought I would add a new stanza for the dune-project file called "map_workspace_root", which, if true would enable this behavior, but if false would not do the mapping. I think the mapping is wanted when you want reproducible results independent of where the build is done. But that does not work for the debugger. I will make those changes and create a PR.

An alternate idea would be to base this on whether debug information is being produced. If you want debug information, then it make no sense to produce incorrect debug information.

Yet another idea is that the debugger should somehow recognize the special "/workspace_root" and perhaps if given workspace path, use that. But that is for another time.

For now will add the stanza and make the default be true. Then if you want correct debug information, set it false. Does that seem reasonable? Will also need to document it in the manual.

[jserot]

Does that seem reasonable?

Yes, sure. This will do the job.

More generally, I think that the debugger support in dune could be improved (making the all thing work is not trivial, esp. for beginners). But, yes, this can wait ;)

Thanks for your help anyway

[richardlford]

I have the changes made to add the new map_workspace_root stanza, but now I'm trying to figure out how to access it from src/dune_engine/action_exec.ml. I would have thought it would be part of the ambient environment, but I've not found it yet.

Note also we could achieve the same result by having Execution_parameters.add_workspace_root_to_build_path_prefix_map return false.

But it is defined in dune_engine/execution_parameters.ml as

let add_workspace_root_to_build_path_prefix_map t = t.dune_version >= (3, 0)

And the execution_parameters type,

type t =
  { dune_version : Dune_lang.Syntax.Version.t
  ; action_stdout_on_success : Action_output_on_success.t
  ; action_stderr_on_success : Action_output_on_success.t
  ; expand_aliases_in_sandbox : bool
  }

does not include a way to get at the dune project.

I will continue looking (learning more about Dune), but do you have any suggestions?

[rwmjones]

Is there a way to default map_workspace_root = false without modifying the build? This causes debuginfo to be broken on Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=2168932

[emillon]

There is not, unfortunately.

At the moment there's a tension between:

• having reproducible builds (in this particular case, not capturing the path where the package is built)
• being able to refer to these build paths after the fact (for example when debugging).

At the moment, we provide a switch that allows switching between a reproducible, undebuggable build, and a non-reproducible, debuggable build. Which is obviously not great. Some work might happen in ocamldebug so that the paths can be relocated again at runtime but this does not exist at the moment

Do you know how debug info works in other languages? or for example how it works in Fedora for a native package like libpng? Does it embed some paths in the compiled binary?

[rwmjones]

Not interested at all in reproducible builds, a solution in search of a problem.

Fedora will use the debug paths to split out the debug information into separate packages along with the source. To find the source it needs to know the correct path.

All we want is some global configuration to override the new behaviour so we don't need to patch every existing package's source.

[nojb]

It seems reasonable to me to have a switch to control this setting from outside the build (eg by passing a command line option to Dune or by using an environment variable).

In fact I'm not sure dune-project is the right place for the stanza in #6988. After all, it is not very useful for a single project to set this setting: you would typically want this setting to be set in all the projects in your workspace.

In other words, I propose to move the map_workspace_root stanza to dune-workspace and allow specifying it also on the command-line of Dune and via an environment variable (which would solve @rwmjones' problem). Note that this is exactly how we specify instrumentation settings.

[nojb]

In other words, I propose to move the map_workspace_root stanza to dune-workspace and allow specifying it also on the command-line of Dune and via an environment variable (which would solve @rwmjones' problem). Note that this is exactly how we specify instrumentation settings.

Incidentally, the name map_workspace_root appearing in a dune-project file should have tipped us off that there was something fishy here.

[Alizter]

Has an issue been submitted upstream to ocamldebug?