|Version 6 (modified by soh_cah_toa, 4 years ago)|
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.
Anything listed with a '?' means that the likelihood of making it into HBDB by the end of the summer is slim.
- read HLL annotations
- read data from debug segment ? code instrumentation (steal from parrot-instrument) ? code introspection (steal from parrot-instrument)
- add debugee interactively with a gdb-like 'file' command
- enable/disable breakpoints
- breakpoints (line)
- breakpoints (function)
- watchpoints (registers) ? reversible debugging
- execute until the next annotation change
- bytecode disassembly ? debugger scripting ? repl
- trace open file handles (including children) ? dynamic memory analysis (check for uninitialized values) ? dynamic memory analysis (destruction-triggered watchpoints)
- print internal debugger state info
- start/continue execution
- single-step execution
- print registers
- source listing