We had been in
a similar situation as yourself, so I’ll share what we have
For many years,
we’ve been maintaining our own debugger, and the API for
communicating with it was gdb/mi (although it wasn’t genuine
In fact, we
even implemented the initial DSF in order to drive our
debugger (though it was not GDB
J) in a way that supported multicore
But over the
years, we found that implementing new features for our
debugger was too hard since any changes had to be done on
The debug agent
on the target, the target-side protocol, the debug engine,
then gdb/mi, and finally the UI talking gdb/mi.
This made us
very inefficient implementing innovations. Also, the DSF,
while designed to simplify Eclipse Platform/Debug APIs,
turned out to
be quite complex in itself and hard to understand and
maintain. Finally, although our debugger had been
gdb/mi from the get-go, we always suffered from “not being
100% GDB compatible”. We’ve found subtle
behavior that cost us a lot of time to investigate and fix
over the years.
So what we did
in the end was, we completely moved to
TCF  as the
debugger infrastructure. There’s two key design principles
In TCF, (a)
API-first design with 100% reliable, extensible public APIs,
and (b) avoid adding too many layers between target and UI.
It’s been a
long journey until we’ve reached full production quality,
but as of today I can say that having TCF made us
implementing new features across a wide range of target
Actually a very
well-known and renowned debugger vendor, who used to offer a
GDB API for their hardware debuggers,
a TCF API just recently and they were extremely happy about
the design of TCF protocol and its APIs.
page 7 on their 2016 newsletter if you are interested.
I’m not sure
which benefits you expect from changing a “direct DSF” debug
adapter to using gdb/mi
additional layer in-between. I’m sure you’ll make the right
design decisions for whatever problems
to solve. I just wanted to make you aware of the experiences
we’ve made and what others have done.
SMTS / Product Owner – Development Tools,
+43.662.457915.85 fax +43.662.457915.6
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.
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?