Logging & Tracing

Since I'm not at EclipseCon this week I trying to get some real work done here in Austin now that the crowds from SXSW have left town. I've been looking into the best way to build good diagnostic logging into the EDC debugger, mostly as a support tool. When people report problems that we can't reproduce we can ask them to create a log of debugger activity that can help us pinpoint the problem.

In Carbide we have a simple diagnostic log based on java.util.logging that works pretty well but then I noticed that Eclipse 3.5M6 includes a new Equinox tracing API. When your application normally keeps a log of activity it is probably best to use one of the various logging services to help manage it. But in this case I just want to be able to get more information to help debug problem situations. It looks like the new tracing API will be a nice way to do this: there is a simple way to trace function entry, exit, exceptions, and simple messages. Each trace call can be tied to a particular debug option so we should be able to turn on tracing for specific parts of the code without getting details about everything at once.

For example this traceEntry call includes the debug option for the EDC run control service and will log the properties passed in and on exit will log the new object created.

public ExecutionDMC contextAdded(Map properties) {
EDCDebugger.getDefault().getTrace().traceEntry(RUN_CONTROL_TRACE,properties);;
ThreadExecutionDMC newDMC = new ThreadExecutionDMC(this, properties);
getSession().dispatchEvent(new StartedEvent(newDMC), RunControl.this.getProperties());
EDCDebugger.getDefault().getTrace().traceExit(RUN_CONTROL_TRACE, newDMC);
return newDMC;
}

Eventually we'll need some UI to help people turn this on and off and maybe some tools to help them send the file or attach it to a bug.

Eclipse Debugger for C/C++ (EDC)

In my last post I talked about how the Eclipse C++ debugger landscape had changed and led us to want a new debugger that’s perfectly tuned to work with CDT/DSF and Eclipse. The existing work in the debug platform and CDT/DSF provides a nice set of services that include user interface elements, commands, and APIs for debug data access. What’s missing is the part of the debugger that knows how to interact with the thing you are debugging to actually get the memory and register values, do run control, provide variable values etc. Traditionally this has been provided by a debugger back-end of some sort: CDT includes an integration of DSF and gdb while other tools vendors have a similar debugger engine, often extracted from their legacy product.

When taking a fresh look at this it didn’t make much sense to create a monolithic debugger back-end and try to integrate it with CDT/DSF. DSF already provides a well designed service model, what’s missing is a complete set of services to flesh out a debugger. Extending the reach of the DSF services into things traditionally done by a debugger back-end would also let us design and develop most of it using the same language, tools, and environment as all of our other Eclipse work.

Yet some services still need to reach out to native code either to interact with a native debug API or to do something performance intensive like parsing symbol files. So we would need a way for our DSF services to talk to the native code that is likely running in a different process or on another device. Fortunately the DSDP/TM/TCF project solves exactly this problem. TCF is a protocol that lets an agent (usually in native code) provide a discoverable set of services to clients (in this case our DSF services). This lets our new DSF services do as much of the work as they can and then use the TCF protocol to talk to remote devices or native code as required.

This collection of DSF services and TCF agents will form the foundation for a complete C/C++ debugger in Eclipse. So we're calling this project the Eclipse Debugger for C/C++ (EDC).

Building a new solution that will let us provide powerful, stable, maintainable, and consistent debugging for the platforms we support (Symbian, Windows, Maemo) means developing DSF services and TCF agents that target them. We’ll end up with a core set of common EDC plug-ins and agents and others that add specific support for a device or operating system. Anything of general interest will be developed within the CDT community and we'll put the Symbian specific work in the Symbian Foundation.

I'll post more details as we develop stuff.

C/C++ Debugger Retrospective

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.

Not Going to EclipseCon

After making the trip the past several years I'm going to have to miss EclipseCon this time. I'd like to be going: I'll miss the sessions, BOFs, and most of all the informal conversations with all the interesting people in the Eclipse community.

But this year our Baby Max arrived a bit early and so I'll be home helping with diapers etc. Maybe I can catch up with everything on Planet Eclipse when I'm up in the small hours.