Debugging native OCaml code used to be painful because the compiler didn’t emit DWARF data. LLDB had no idea where your source lines or variables were. With DWARF v5 support, the compiler now includes proper debug info — line mappings, symbols, and variable names — so LLDB can actually follow your code.
A small LLDB Python plug-in reads OCaml values at runtime and prints them in a readable form: lists, tuples, closures, strings, etc. It follows DWARF location lists to track where each variable lives and uses the runtime headers to decode them. The `p` and `ocaml_vars` commands work like normal LLDB commands but understand OCaml values.
It’s not complete yet (records and variants still show as tuples), but it makes debugging native OCaml code straightforward. You can finally set breakpoints by source, inspect locals, and understand what’s in memory without switching to disassembly.
Debugging native OCaml code used to be painful because the compiler didn’t emit DWARF data. LLDB had no idea where your source lines or variables were. With DWARF v5 support, the compiler now includes proper debug info — line mappings, symbols, and variable names — so LLDB can actually follow your code.
A small LLDB Python plug-in reads OCaml values at runtime and prints them in a readable form: lists, tuples, closures, strings, etc. It follows DWARF location lists to track where each variable lives and uses the runtime headers to decode them. The `p` and `ocaml_vars` commands work like normal LLDB commands but understand OCaml values.
It’s not complete yet (records and variants still show as tuples), but it makes debugging native OCaml code straightforward. You can finally set breakpoints by source, inspect locals, and understand what’s in memory without switching to disassembly.
I didn't write a single line of code in this PR but I carefully shepherded it to completion over the several days.