Ho there folks. As some of you may already be aware, I have been working for some time on a debugger project for Linux partly for fun, partly to investigate what can be done if you do not use gdb as a back end and partly as a potential kick-off point for a serious effort to improve the experience of debugging handmade type projects on Linux.
I have not settled on a name for the debugger, the working name is "drake", but perhaps something like "owldb" or "piggy" would be more appropriate.
So far I have:
* a very hacky exploration of ELF+DWARF decoding which is somewhat like readelf in function, written from scratch with no libraries beyond the C runtime.
* a basic ptrace-based debugger using SDL2 for graphics, udis86 for disassembly, libelf+libdwarf for binaries and the C runtime.
The debugger has the following functionality at the moment:
* Standalone launch directly on executable (curiously, I've not actually done command-line parsing for this yet)
* Spawn process for debugging
* Single instruction stepping
* Resume/continue debuggee
* Software breakpoints
* Watch pane showing all in-scope variables, and registers
* Disassembly pane (can disassemble from binary or debuggee memory)
* Threads pane with basic stack walking and symbol resolution
* Source pane
* Source file select (can only select source files referred to by the executable at the moment)
* Highlight of breakpoints and currently executing line in source and disassembly pane
* Partial multi-threading support (select "current" thread, resume all threads, single step one thread, threads view lists all threads)
* Support for inspecting information from dynamic libraries (from both the runtime link step and dlopen())
I'm currently working on implementing step over/step in to next line (currently steps are per-instruction only).
Other functionality I want to implement (some mundane and some more aspirational):
* Watch specific variables, memory locations and expressions
* More stepping types and targettable step-into
* Thread controls (eg step and resume single/multiple thread, freeze and thaw threads)
* Memory explorer
* Hardware breakpoints (mainly to allow data breakpoints, and probably for performance wins on some operations)
* Conditional breakpoints
* Call debuggee functions
* C lexer/parser to enhance the debug information and provide better feedback on the UI (debug info doesn't tell you everything about how to tie things to source code, and generally seem to work on a line rather than sub-line granularity)
* Integration with an editor (4coder if mr4thdimention is willing)
* Data observation breakpoints (collect values of variables at certain points, tabulate and visualize)
* Customisation via a C layer (explore the possibilities here, like custom visualisations, render debug info to game (or game to debugger controlled surface), understand more about user types/data structures and systems).
* Deterministic record (to provide reversible debugging and improved bug recreation)
I'm sure there's a bunch of things I've forgotten from that list.
I'm not really at my first milestone yet, which is to run the Linux version of HandmadeHero and perform some real debugging task on it (perhaps reenact solving some bug from the stream).