@run foo()
: run foo()
inside the debugger.
When a breakpoint is hit, then you will be given an Iron REPL to work with-in,
allowing you to view/manipulate the arguments.
@enter foo()
performs similarly, after immediately breaking on the first line.
Within this you can read (and write) variables,
- Step-Next: to move to the next IR statement
- Step-In: to debug in the next function call (assuming next is a function call)
- Step-Out: to debug from the next statement the function that called the current function
- Continue: proceed to next breakpoint
- Abort: terminate running the debugger.
set_breakpoint!([function|method])
: Set a breakpoint on call to the argumentset_breakpoint!(filename, line number)
: Set a breakpoint on the given line in the given functionset_uninstrumented!([function|module])
: Disable debugging in the given function/module- Not having debugging enabled for modules/functions you do not need to debug massively speeds up the running of your program.
- However, debugging is fully disabled for those modules/functions, so if those functions would then call functions you do want to debug (say by using
map
) then that will also not be caught by the debugger.
list_breakpoints()
,list_uninstrumenteds()
: list all the breakpoints/uninstrumentedsrm_breakpoint!(arg...)
,rm_uninstrumented!(args...)
: remove breakpoints/uninstrumenteds. Takes same arguments asset_...
.clear_breakpoints!()
,clear_uninstrumenteds!()
: remove all breakpoints/uninstrumenteds.