[Contents]   [Back]   [Prev]   [Up]   [Next]   [Forward]  

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:

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:


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:

[Contents]   [Back]   [Prev]   [Up]   [Next]   [Forward]