Debugger interface

Plan

• use lua's mobdebug library to interface [ZeroBrane Studio] (http://studio.zerobrane.com/)
• provide enough run-time reflection (frame info, backtrace, ...)

Internals

DEBUG ops are added by the compiler for each new line in the bytecode vm only (ignored in the jit). The op contains the link to the AST, which includes also the ast->loc.lineno. Note that for multi-line blocks and functions currently the last line is stored, not the first. (-> issue #?)

Each proto contains a list of ASTs (f->debugs) which the debug op is referring to. pn_filenames is a global list of filenames, which are referenced by ast->loc.fileno.

API

There's a lib/potion/debug.pn module exporting the debug class and object, which should offer all the needed reflection, similar to the lua debug module, and 2 more submodules: lib/potion/debug/remote.pn over a tcp socket on port 8172, and lib/potion/debug/z.pn with the serialization needed for ZeroBranes Studio.

• -d loads debug.pn and calls debug()
• -dz loads debug/z.pn and calls z.debug()
• -d=args loads and calls debug(args)
• -dremote=args loads and calls remote.debug(args)

args is just a plain string, comma splitting needs to be done in the module. e.g. -dremote=host,10.0.0.1,port,3174

Reflection objects and methods

The debugging interface should expose the following objects

• :debug (global debug object, bound to the debug object, prefixed with :)
• :ast (current ast)
• :cl (current closure)

Methods API (from lua)

• debug getinfo = (level, name): .
• debug getlocal = (f, i): .
• debug setlocal = (f, i, name): .
• debug setupvalue = (f, i, name): .
• debug traceback = (f| level): .
• debug sethook = (hook, name): .

Profiler: not instrumenting the VM

It's much easier and better to use an external time-sampling profiler, like darwin Instruments or cachegrind, than to instrument the vm by your own.