We're doing some new work on the debugger in Carbide and for some perspective I'll take a look back at how the Eclipse C/C++ device debug landscape has changed in the past few years.
When we first began designing our Carbide.c++ tools for Symbian mobile development a few years ago there was a lot of new activity around C/C++ debugging in the Eclipse community: The CDT project offered a proven set of APIs for debugger integration (CDI), but as vendors continued to move their existing debuggers into new Eclipse based environments it was clear that more work needed to be done to meet the expectations of veteran C/C++ developers.
Our team began creating C/C++ tools for Symbian using the CodeWarrior IDE and when we designed a new generation of Eclipse based tools we decided to reuse its proven debugger engine and hook it up to CDT/CDI. While this let us quickly deploy a good C/C++ debugger as an initial step, we also carefully watched developments in the device debugging project (DSDP/DD) and the creation of the Debug Services Framework (DSF, now part of CDT). It was also exciting to see the many improvements resulting from the debug platform team’s engagement with the device debug community. We began developing a list of improvements we would like to make to Carbide's debugger that would be difficult to do without using the new work in the platform and DSF.
At one point I started prototyping an integration of our debugger engine and DSF. While I got a number of things working it also became apparent that it wasn’t a very good fit: DSF uses a highly asynchronous service model for supplying information about the debug session and our debug engine didn’t work that way. I was having to rig up a lot of stuff in a clumsy way to make it work with DSF. To move our debugger forward it was looking like we would not only need to move to DSF but also rework a lot of our debug engine.
Doing that work looked difficult because the engine code was pretty convoluted and much of it needed an overhaul. Also the engine was closed source licensed code and this would be a issue as we moved to open source all of Carbide along with the Symbian Foundation.
So that’s how we have moved from our initial legacy debugger integration with CDT/CDI to how it looks today: lots of promising development in the CDT and device debug community but we're not yet able to take advantage of much of it with our existing debugger. So we started thinking about something new that we can develop in the open and tune to work perfectly with DSF and Eclipse.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment