Review of previous work

DDD (and xgdb, xxgdb, mxgdb, ...)

Each of these debug GUI interfaces are implemented using an identical technique. GDB (or some other debugger) is started as a separate server process, debug commands are sent to that process and all output is then parsed. Of these, DDD is probably the most successful.

Unfortunately this technique has several limitations:

• it is very sensitive to changes in GDB's output
• performance is restricted by the speed of communication of between the GUI and GDB
• it was difficult to keep the GUI consistent with the CLI

Insight (a.k.a. GDBtk)

The initial GDBtk implementation was very like DDD except that it was embedded in the same process as the debugger. Commands would be sent to GDB and the resultant output would then be parsed. As GDBtk evolved, and bottle-necks were identified, more direct calls into GDB's internals have been implemented (ex the assembler window).

Limitations of GDBtk can be identified:

• the need to share an event loop with GDB
  With the introduction of an event loop and the asynchronous in GDB it will finally becoming possible to address this issue.
• As with DDD GDBtk was often affected by changes to GDB's output
  The recently introduced gdb-file object should provide significant help.

EMACS/annotate

GDB can produce annotated text output through the set annotate command. In addition to the normal text, GDB includes numeric markers that identify key output tokens (a line number, a file name). EMACS parses the annotations and makes use of that information.

The one key failing of this annotate mode is that the output fields are identified numerically instead of symbolically as found things like XML.

While the annotate code is not being actively developed it does have a significant installed base and consequently needs to be maintained.

libgdb 1.0

libgdb 1.0 was an interesting learning experience. Much of that experience is being transfered to libGDB. Issues that libgdb didn't address were:

• an event model and a notify mechanism
• the assumption that reasonable performance could be achieved while relying purely on a textual interface.