Byte target can't be debugged with ocamldebug

[disposedtrolley]

Expected Behavior

dune build should produce a byte target for https://github.com/disposedtrolley/hello_ocaml which is able to be debugged with ocamldebug. A breakpoint should be able to be set on line 2 of the helloworld module.

Actual Behavior

While dune build is able to build a .bc file, it seems to be missing debug symbols. For example, attempting to set a breakpoint on line 2 of helloworld.ml results in:

hello_ocaml · (main) ⟩ ocamldebug _build/default/helloworld.bc                         ~/p/o/hello_ocaml 2
        OCaml Debugger version 4.12.0

(ocd) break @helloworld 2
Loading program... done.
Can't find any event there.
(ocd)

When the project is built with ocamlc -g helloworld.ml, the resulting a.out file can be debugged with ocamldebug correctly.

Reproduction

• PR with a reproducing test:

1. Clone https://github.com/disposedtrolley/hello_ocaml
2. Run dune build
3. Run ocamldebug _build/default/helloworld.bc
4. Type break @helloworld 2
5. Observe that the debugger outputs "Can't find any event there."

Specifications

• Version of dune (output of dune --version): 2.8.4
• Version of ocaml (output of ocamlc --version) 4.12.0
• Operating system (distribution and version): Fedora 33 (x86), macOS 11.2 (arm64)

Additional information

I've tried this with OCaml 4.12 (on macOS with Apple Silicon) and 4.10.2 (on macOS with Apple Silicon and Fedora 33 x86).

[ghost]

Thanks for the detailed report. I had a look and found the issue; it is because of the name mangling Dune does to avoid collision between modules of different libraries and/or modules of the executable.

More precisely, OCaml has a flat namespace, meaning that the name of each compilation unit (= toplevel module) must be unique. So if library A has a toplevel module named M and library B also has a toplevel module named M, then A and B cannot be used together in the same program. To workaround this limitation, Dune compiles modules of libraries and executables to compilation unit with a long name. For instance, module M of library A is compiled to a__M.cmi, a__M.cmo, etc... To recover the short names, Dune generates a file that aliases the long names to the small one and open this module in all modules of the library. This module is also used as the interface of the library, unless it has a module named after the library name. Given that such clashes can happen with the modules of the executable, Dune does this mangling for executables. More precisely, a module M of an executable is compiled to dune_exe__M.cmi, dune_exe__M.cmo, etc...

We tried to hide these long names, but unfortunately they sometimes leak. Debugging is an example where you will see these long names. So here, you need to put the breakpoint on @dune_exe__Helloworld rather than @Helloworld:

$ ocamldebug ./_build/default/helloworld.bc
	OCaml Debugger version 4.11.1

(ocd) break @dune_exe__Helloworld 2
Loading program... done.
Can't find any event there.
(ocd) break @dune__exe__Helloworld 2
Breakpoint 1 at 0:10504: file helloworld.ml, line 2, characters 3-35
(ocd)

We should probably document this in the manual. It is unfortunate that users have to do this, but unfortunately we can't solve it just on the Dune side.

[ghost]

We discussed this issue during the Dune meeting today. It would be nice if ocamldebug could handle this better. The compiler already understands this name mangling in a few places, so it would make sense to add a heuristic in ocamldebug so that the short name works.

On the Dune side, we'll consider this issue fixed when this is documented in the manual.

[disposedtrolley]

Thanks @jeremiedimino for the explanation! I'm very new to OCaml so it was great to get a better understanding of flat namespacing and its consequences with how internal and external modules interact.

If contributions to documentation are welcome, I'm happy to update the relevant section in the Quickstart with the information you've shared here?

[ghost]

Such contributions are definitely welcome, please go ahead :)