| Re: [cdt-dev] Hooking into GDB/MI |
|
A side note, to avoid confusion. I don't intend to use *gdb* nor the MI wire format at all; no GDB process is being launched. The idea is to replace the GdbControl
and intercept MI command objects before they make it onto the MI output stream and then create MI response objects (*Info) and inject them into the corresponding request monitor. This means that we do not need to care about the MI wire format and the scary
places where DSF/GDB parses gdb's human-readable commands (e.g. "info threads").
The communication between Eclipse and the backend debugger process is done using Apache Thrift, which is a really nice RPC framework. /Jesper From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc Khouzam 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. BR, From: Doug Schaefer <cdtdoug@xxxxxxxxx> I find it telling that we seem to always pull back and try and make our debuggers MI compliant rather than deal with the complex parts of DSF. I've long been a doubter of DSF since Pavel first presented it to us at the CDT summit back in
2006. And nothing I've heard people say has done anything other than confirm my fears about it's complexity.
One of my mantras is that if it takes longer to implement my feature with a framework than without, then that's not a very good framework. I'm not saying DSF is one of those but I am curious to find out whether building a debugger integration
directly to the platform debug APIs, as TCF has done, would give better results. That way you can leverage the good things about your debugger instead of trying to make it fit the MI mould. We still have two debuggers out there that we need integrations for, cdb for Windows, and I still think there would be benefit to support lldb directly (though out-of-process, but with a protocol that maps one-to-one with it's API). Once
I get through my pile of things on my table for the next year or so, maybe I'll give it a go. Would be an interesting exercise. Doug. On Thu, Mar 24, 2016 at 7:39 AM, Jesper Eskilson <jesper.eskilson@xxxxxxx> wrote: 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". On 2016-03-24 12:01, Oberhuber, Martin wrote:
--
|