What's left to do?

There are two broad categories of things that remain to be done:

• easy boilerplate things
• more fundamental things

Easier things

Let's start with the easy things since they are easy. Most of these amounts to porting code from my other debuggers. Here are some of these things:

• A more complete gdb command set. A good deal of this is just porting say the Ruby code.
• Remote execution and a JSON-like remote interface. Again, in my other debugger projects I've done this so I have a good idea of what's involved. Not difficult, just coding.
• Source-line display and syntax colorization (my Ruby linecache, or Python pyficache module). Until this is done my Emacs debugger interface may be of use. The code in git supports gub.
• on-line help (via godoc?). My python debugger uses pygments and ReStructured text while my Perl debugger uses perlpod.
• Command completion, fancier GNU ReadLine support. But I do have minimal GNU Readline bindings in package go-gnureadline.

Harder things

That said, my focus I think will be on the harder things, well, because they are harder.

The big thing is adding an evaluate-string function. And one can do this in several incremental steps:

1. evaluation of identifiers, simple and compound
2. constant expressions with or without variables, identifiers, functions
3. expressions which are read-only
4. read-write expressions
5. dynamic imports

String evaluation is also important if one wants to provide an interactive shell.

A more complete interpreter. I've redone os.Exit() and syscall.Exit(), added runtime.Caller() and runtime.Callers(), albeit the latter is less than satisfying. Adding runtime.Stack() is easily doable. But there are many more things remain.

I think the SSA-interpreter in go-tools is pretty good. Perhaps this project will give more visibility to the other one, and that more people will get involved to complete both. I believe an improvement to one interpreter in terms of completeness will lead to an improvement in the other.

Things

Separated Debugger information

Right now information for the debugger has been added to existing interpreter structures. An example of this is a hash table in the AST Function structure which maps a local variable name to an index into the local table. Better would be to put all this in a separate place perhaps in a separate file which is loadable on demand.

Here are some of the things I know about

• LocalsByName which maps a local name into on index into Function.locals
• trace instructions which are inserted into a function's instruction sequence. This could be a structure that is outside of the instruction sequence. An advantage of having this be an instruction is that it survives outside of instruction motion or elimination
• Frame.Breakpoint: like the trace instruction this could be parallel information on an instruction or Function.
• BasicBlock.Scope: like the trace instruction this could be parallel information on the block

In the interpreter, I've added a mechanism to get goroutine heads. Since this is useful in of itself, see runtime.Stack(); it is less clear this should be separated.

Other things

One thing I suppose that could be put under "Easy things" has to do adding an position interval type sort of akin to a token.Pos and using that instead of position pairs which sprinkled too often throughout the interpreter and debugger. This is part of possibly a broader category of things that really should be pushed into earlier stages and libraries like go/ast but for whatever reason hasn't gotten traction.