streamGDB Architecture

Stan Shebs argues that, overall, the existing text based command line interface to GDB has served its clients well (xgdb, xxgdb, mxgdb, DDD, CrossWind).  Stan does, however, identify a number of limitations with the existing text based mechanism: To address these issues, Stan proposed:
[...] an alternate form of the CLI that is regularized for the benefit of programmatic instead of human users.   This interface will still be textual, but the commands will be shorter and have only a single fixed form, and the output will appear as structured data, also in fixed forms and identified by type
Any code rendering data (such as breakpoint information or target variables) would need to be modified so that the the information could be displayed in both programmatic and more natural human readable forms.  For instance, the function mips-tdep.c:mips_do_register_info() contains code to render the MIPS register set in a form palatable to humans.  In the programmatic version of GDB, this code would be modified (duplicated?) so that the data was rendered in a more programmatic form.

A GUI debugger would then implement an adapter that matched their requirements with that of the programmatic GDB interface.

Problems and limitations

Jim Blandy raises a number of concerns about this approach.  In particular, Jim identifies the issues: The clear resolution of these and other issues is part of the Headless GDB project.