| [cdt-dev] Hooking into GDB/MI |
|
Hi, As some of you know, we have a debugger (C-SPY) for which we have a DSF-implementation which does not use GDB. We have implemented our own set of DSF services, and this has worked fairly well over the last few years. Inspired by the CDT hackathon, I wanted to take a stab at an idea I've had for a while, namely to "disguise" our debugger as GDB. The purpose would be to avoid having our own implementation of some rather hairy DSF service logic and also
to be able to be in a better position to contribute code to DSF/GDB as well as leverage from new features being implemented in DSF/GDB. After doing some research on GDB/MI I realized that it would be nice if we could avoid having to reimplement the GDB/MI wire protocol. Since the MI commands are nicely queued by the GdbControl service, I thought that one might be able to
intercept them in e.g. queueCommand(). Each MI command would then need to be "interpreted" to interact with our debugger. Before really digging any deeper into the intricacies of the DSF/GDB/MI internals, I thought I'd post an open question here about this. Does this seem like a reasonable idea? Or should we stay with our own DSF implementation? Cheers, /Jesper -- Jesper Eskilson
Developer IAR Systems AB |