| Re: [cdt-dev] Hooking into GDB/MI |
My understanding is that Jesper's idea of implementing an MI interface is not to avoid DSF but to leverage DSF-GDB. After all, Jesper has been directly using DSF for years.
Yes DSF is complex, but then again, if one wants an asynchronous, efficient, feature-rich, extendable solution, integrated in the existing eclipse Debug platform, I think complex is to be expected :)
But let's think further about the idea of leveraging DSF-GDB. We shouldn't ignore that DSF-GDB is a *GDB* integration. Making it work with another debugger using MI is definitely possible, lldb-mi is one example (I believe there is a small patch in the works to bring that support to CDT as we speak). But Martin describes some insightful experience: subtle differences in behavior between the new debugger and GDB could, and most probably will, relatedly cause problems.
Another point we didn't discuss is that DSF-GDB gets a lot of its extra features by leveraging GDB. Would another debugger provide similar advanced features in a way compatible with MI? If the list of such compatible features if small, then how much benefit would DSF- GDB bring to a scenario where Jesper already has all the DSF services implemented for his debugger anyway?
So I would start by listing what features one is looking to gain from using DSF-GDB, and confirming they will work with the new debugger in an MI-compatible way.
Some of the desired features may even be backbend independent. I'm thinking of Enhanced Expressions, Register Groups, Hiding Running Threads, Step-into-selection, Run-to-line, Per-element format, the Multicore Visualizer, and more. Such features have been implemented in DSF-GDB, but could probably be extracted to DSF (although that would need to be confirmed on a car by case basis).
So it is possible that one can get many more features for DSF by spending the time extracting them from DSF-GDB into DSF. This would be a more stable alternative than trying to make one's debugger look like GDB. But it would also be an continuous effort as new features are put into DSF-GDB, unless of course you worked closely with the community and tried to get people to implement features directly in DSF when possible.
I'm surely not making the decision any easier, but it is a complex reality. Like DSF :). But also like Eclipse.
Thanks for your input, Martin. TCF is still on my radar as possible options. One thing I found difficult with TCF when I did some early experiments on it was that the existing code (e.g. the reference agent) was very much focused on embedded linux, something which is not really relevant for us. But in the end I abandoned by experiments partly due to lack of time and partly due to the fact that we had a system which was working "well enough".
I like the services-based architecture of TCF and even if we probably will not use TCF itself we will (and in fact already are) using many of its ideas.
/Jesper
On 2016-03-24 12:01, Oberhuber, Martin wrote:
Hi Jesper,
We had been in a similar situation as yourself, so I’ll share what we have done:
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 GDB).
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 well.
But over the years, we found that implementing new features for our debugger was too hard since any changes had to be done on many levels:
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
designed around gdb/mi from the get-go, we always suffered from “not being 100% GDB compatible”. We’ve found subtle
differences of 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 [1] 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
extremely fast implementing new features across a wide range of target operating environments.
Actually a very well-known and renowned debugger vendor, who used to offer a GDB API for their hardware debuggers,
has implemented a TCF API just recently and they were extremely happy about the design of TCF protocol and its APIs.
See page 7 on their 2016 newsletter if you are interested.
Bottomline:
I’m not sure which benefits you expect from changing a “direct DSF” debug adapter to using gdb/mi
as an additional layer in-between. I’m sure you’ll make the right design decisions for whatever problems
you’re trying to solve. I just wanted to make you aware of the experiences we’ve made and what others have done.
[1] https://wiki.eclipse.org/TCF
HTH,
Thanks,
Martin
--
Martin Oberhuber, SMTS / Product Owner – Development Tools, Wind River
direct +43.662.457915.85 fax +43.662.457915.6
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Jesper Eskilson
Sent: Thursday, March 17, 2016 9:28 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [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
_______________________________________________ cdt-dev mailing list cdt-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cdt-dev
--
Jesper Eskilson Development Engineer
IAR Systems AB
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev