This page exists to help plan out soh_cah_toa's GSoC project. Unfortunately it turns out to depend heavily on parts of imcc which were substantially more broken than anyone realized. Although imcc has gotten the attention of our developers, the GSoC project's schedule shouldn't make any assumptions as to whether imcc will improve. My (cotto) plan is to rework hbdb's schedule so that it can be a maximally useful debugger by the end of GSoC within the limitations of what imcc can provide. The first step is to break the original schedule into a list of discrete features and to divide those features into three groups: those that are completed, those that depend on imcc's broken line number annotations and those that don't. From there, we can work out a new schedule that will show measurable progress and be completable while avoiding some of the more egregious landmines provided by imcc.

the original schedule (with some omissions unrelated to features) is included below as a starting point.

Specific Details

Read bytecode annotations and debug data from currently running code.

This would effectively extend the debugger's "vocabulary" from PIR to all Parrot-supported HLL's.

Add an interface for code instrumentation and introspection, possibly stealing from parrot-instrument.

Create an extension that would open an interpreter and be able to run code within it one opcode at a time.

Implement a shell as a user interface. Will be able to able to interpret commands, display information about current location, etc.

This may as simple as an NQP eval loop with a global dispatch table for user commands.

Use the FileHandle PMC to make the command shell a little more friendly. We can also add command line editing, command history, and tab completion.

A basic command set would include things like:

Start and continue execution with the ability to add arguments if they're not specified on the command line.

Creating breakpoints at a specific line or function.

Watch Parrot registers (including PMC's).

Stepping through code either forward or backward. Execute either a single PIR opcode or all opcodes until the next annotation line change.

Changing the current working directory of the program.

Backtrace using the CallContext and Exception PMC.

Bytecode disassembly (possibly with pbc_dump).

Scripting. For instance, interpreting a file as a set of debugger commands.

There's much, much more that can be added in the future. These are just a few.

Trace all open file handles.

This would also mean it'd have to trace all child processes.

Dynamic memory analysis.

Check arguments to function calls for uninitialized or invalid values.

Place a watch on all or individual PMC's to detect when it has been reclaimed by the garbage collector.

Timeline:

Begin designing initial set of commands. A good starting point would be: enable/disable breakpoints, start/continue execution, stepping, print registers, source listing, help, etc

commands for bytecode disassembly, command scripting, printing information about the interpreter, etc.