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:
The output format of the GDB commands are not precisely defined. GDB's
human readable output can (and often does) change in response to user feedback.
There is very little control over the volume of output, which means that
a GUI will need to spend time sifting through a large volume of data to
find just the values it requires.
GDB may mix output from several sources, such as when "display" commands
are used and when a program issues output through GDB.
[...] 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
Amending GDB to produce two kinds of output increases both the complexity
of the code and the maintenance overhead.
The current GDB allows the interspersion of data with error and warning
messages and target console messages on the output stream. The proposal
does not provide a formal (machine checkable) mechanism to ensures that
non data output gets correctly directed away from the data output stream.
Such a mechanism should ensure that both the existing occurrences of this
problem were fixed and that future updates were not able to re-introduce
[the proposal does not] force programmers to be explicit about how the
interface changes, make an opportunity to consider carefully how the interface
should change, and provide a convenient focus for the person responsible
for keeping that interface clean.