Nice post, thanks !
A few things I would like to add:
- Time travelling is possible for the native debuggers with
rr. At some point it was Linux-only, it might still be the case, but it’s very nice to use. I have on some occasions debugged bytecode programs by usingrron it, and with the appropriate gdb/lldb macros to print OCaml values it can be useful (but mostly for debugging the C parts; for problems purely on the OCaml sideocamldebugis still better suited). I use it regularly for native debugging and it’s very convenient (it can even help with debugging eisenbugs in parallel programs ! Just runrr record ./my_programseveral times until the bug triggers, and thenrr replaywill always replay the same run, including thread interleavings, consistently reproducing the bug). - I have tried time travelling with
ocamldebugin the past and I have hit some serious issues: limited history means that you cannot go very far in the past, and the way it works (by setting checkpoints and replaying from the checkpoint to the required instruction) means that you can often see weird artifacts due to C calls being replayed each time you step back, sometimes breaking the program completely. I’m curious to know if this is just bad luck (or me doing weird things), or if you had similar issues too. - The
Dune__exestuff is, I believe,dune’s misguided attempt to shield users from potential conflicts between files linked in the executable and modules with the same name present in non-wrapped libraries required as dependencies. I suspect that(wrapped false)or something like that in the section of the dune file corresponding to the executable will get rid of it.