Debugging

A Nova program is debugged as the C it compiles to, with the C mapped back to Nova lines, so lldb and gdb work without knowing anything about Nova.

A debug build

novac build -g main.nova -o program
lldb ./program          # or: gdb ./program

-g writes #line directives into the C and compiles it with -g -O0. Breakpoints then go on Nova lines, and stepping moves through Nova statements.

	lldb	gdb
Stop at a line	b main.nova:12	break main.nova:12
Stop when a check fails, before the program exits	b nova_panic	break nova_panic
Where am I	bt	bt

Names

The C names follow fixed rules, so a Nova name is easy to find:

Nova	C
function length	nvF_length
method Counter.bump	nvM_7Counter_bump (the type's name, prefixed by its length)
local or parameter sum	v_sum_1
a temporary the compiler made	t_3
field x	f_x
struct Point	nvT_Point
an item of a dependency geometry	nvF_geometry_area, nvT_geometry_Point

Nova names in the debugger

editors/debug adds two commands that print with Nova names:

lldb ./program -o "command script import editors/debug/nova_lldb.py"
gdb ./program -ex "source editors/debug/nova_gdb.py"

• nova-locals: the current frame's locals and parameters, without the compiler's temporaries, with struct fields by their Nova names: p = { x: 3, y: 4 }.
• nova-bt: the backtrace as Counter.bump at main.nova:6.

(lldb) b main.nova:12
(lldb) run
(lldb) nova-locals
p = { x: 3, y: 4 }
sum = 7
(lldb) nova-bt
length at main.nova:12
main at main.nova:18

When the program panics

A failed check prints the reason and the Nova location, and exits with status 134. Under a debugger, a breakpoint on nova_panic stops at the moment of the panic, with the whole call stack to inspect:

(lldb) b nova_panic
(lldb) run
(lldb) nova-bt
nova_panic at nova_rt_core.c:207
nv_add_u8 at rt.h:190
grow at main.nova:2
main at main.nova:7

For memory errors in unsafe code, novac run --interp is often faster: the interpreter stops at the first invalid access and names it.