CDT-EDC Multi Context Debugging

If you are ever at a gathering of the Eclipse CDT community and the conversation starts to drag just casually ask about support for debugging multiple processes, cores, or contexts at the same time. You'll hear about a lot of important interrelated issues and that the committers have been chipping away at them for some time.

One of the nice things about creating the EDC C/C++ debugger in CDT was the opportunity to include ground up support for debugging many contexts at once. But while that's fine under the hood we immediately ran into an important usability issue in the Debug view.

When you launch a debug session you start with a launch configuration that tells the debugger what to do and you end up with a Launch in the Debug View that shows the result. The Launch is usually named after the launch configuration that created it:

When you want to debug something else you can use another launch configuration that will create another Launch in the Debug View:

People find this confusing if both the things you are debugging are running in the same target environment. They expect them to be grouped together in the Debug view and they expect the Launch at the root of the view to represent the overall environment (phone, PC, multi-core system etc.)

The EDC debugger deals with this by letting new launches join existing ones if they are part of the same target environment. For example if you debug a Windows app (Simple.exe) you will get a new debug session and Launch in the Debug View.

Debug a second Windows app (BlackFlag.exe) and it will join the existing one:

EDC uses a description and image of the target environment provided by the debugger implementation. In that case it was the Windows machine name. In this one it's the name of my phone:

Of course there are lots of other issues related to multi context debugging. To see how the CDT community is addressing these you can follow along with the CDT multi-core working group.

CDT-EDC Where is the Exit?

Our team is working on our next generation of C/C++ development tools for Symbian, Carbide 3.0 (C3). These build on the Eclipse Debugger for C/C++ (EDC) that's part of the CDT project. Our test team reported a bug that raises an interesting question for developers: do you want the debugger to show you what's really happening even if it seems a bit confusing?

Here is the situation: you are debugging a C++ function that looks something like this:

Say you are stepping through this function in the debugger and you start at line 31. "value" happens to be 200 so the condition on line 31 fails. You step over and end up on line 36. Step over again to go to line 37. So far everything looks OK. Now you step again from line 37 and you might reasonably expect to exit the function. Instead you end up on line 34! This looks like a heinous bug but is a case of the compiler reorganizing things even in a normal debug build with optimizations off.

The compiler has built this function by putting all of the return/exit code in one place, in the middle of the function at line 34. At the end of the function, at line 37, instead of generating the exit stuff again it simply jumps to the address at line 34 and exits there. It dutifully and accurately records this bit of slight-of-hand into the symbol information and the EDC debugger shows you on line 34.

Should the EDC debugger try to detect this just to avoid confusion? Another perspective is that the debugger should show you exactly what's happening even if the result is sometimes puzzling. What do you think the EDC debugger should do?

Giant Symbols

The Carbide team here at Nokia has spent the last couple months working on getting the Carbide 3.0 (rebranded C3) beta out to developers, doing an update to the current tools (Carbide 2.6) and wrapping up our contributions to the Eclipse Helios release, mostly in the C/C++ Tools project (CDT).

In the midst of all that I was asked to help a developer who is porting a very large productivity app to Symbian. His problem involved using the debugger in Carbide 2.x and the size of the symbol files generated for his application. A symbol file is generated by the build tools and contains the information used by the debugger to make sense of your source code, variables, and most of the other stuff you see in a debug session.

With all the apps developed at Nokia we've seen a lot of large symbol files but this one was nearly a 1GB, almost double the size of our largest sample. Our current tools (Carbide 2.x) crashed when trying to open the big symbol file and couldn't easily be fixed to handle something that size.

This is one of the use cases we had in mind when we developed the new debugger in C3, the Eclipse Debugger for C/C++ (EDC), part of the Eclipse CDT project. So we ran our new big symbol file sample through the EDC symbol reader unit tests and everything worked quickly and smoothly. I gave the developer a beta build of C3 and once we worked through some setup issues on Windows 7 he was able to debug the app with the giant symbol file and see all the debug info.

Then he says "that's the symbol file for just one of our dlls, all together we actually have about 14GB of symbol data." So I think we have now put the EDC debugger in C3 through a least one kind of worst case scenario.

While all this was going on someone asked why the symbol files were so large to begin with. This big productivity app has been ported to lots of platforms with different tool chains and they never ended up creating such a large amount of symbol data. After some investigation they discovered a build flag called "remove_unneeded_entries" that, when enabled, dramatically reduces the size of the symbol data. We still have more testing to do but so far it looks like it really helps debugger performance with no loss of useful data.

Carbide, CDT & EDC at EclipseCon 2010

Had a great time at EclipseCon in Santa Clara last week. Some highlights:

 Face time with our colleagues from Nokia, the Symbian Foundation, Eclipse and CDT communities. Ronnie King, Warren Paul, and I came from the Austin office and had a great time catching up with people we usually don't get to see in person very often. I missed EclipseCon last year but I heard attendance was up and organizations were able to send more people this time.

I really liked the session format: the reduced times seemed to really focus the presentations and kept a wide variety of material flowing throughout the day. I know the CDT session Doug and I did seemed to fly by quickly.

Had a great response to the new EDC (Eclipse Debugger for C/C++) that will be in Carbide 3.0 and our team is contributing to CDT 7.0. People liked the overall concept, features, and extensibility and I think we'll soon start seeing more contributions from the community.

Lots of discussions about usability and performance, both very important to us for Carbide. There is new work going on in the Eclipse & CDT communities that will help us smooth out some rough spots our Carbide users have had to put up with.

Visiting developers at the Nokia office in Mt. View. We love getting to shadow developers around and watch them work. Great unfiltered feedback. We had a chance to introduce them to some features in Carbide they didn't know about and help them through some difficult issues that are tough to understand unless you can look over the person's shoulder.

Aligning Carbide 3.0 with Eclipse Helios

Like most teams that build C/C++ tools on top of Eclipse & CDT we have been building Carbide with the latest platform release and a somewhat forked version of CDT. This made sense as most of our releases have shipped in the winter or spring, long after the last major Eclipse release. But with the next major release of Carbide due after Helios we’ve jumped on the opportunity to align more closely on Eclipse 3.6 and CDT 7.0. How closely? Well, we’ve just started creating our Carbide builds with 3.6M5 and the CDT 7.0 sources straight out of the eclipse.org CVS repository.

We hesitated to do this in the past because it means we effectively have the entire CDT team contributing to Carbide in real time: any one of the committers can break our build or introduce bugs. But we’re more confident now and our experience with the CDT community has been very good: people rarely break the build and the quality and review of contributions has been excellent.

And since we sync up with the latest platform and CDT eventually anyway is makes more sense to discover any issues at the moment when the work is developed and contributed, not months later. Now both our internal test team and the Carbide beta group can give the new platform and CDT stuff a workout before it’s released. This also lets us get rid of our internal copy of CDT we would occasionally sync with the public one. Trying to keep it updated was a pain and it created a temping way for us to make changes that weren’t really ready to go back into the community.

CDT-EDC and Openness

While our team here at Nokia has been developing the Eclipse Debugger for C/C++ (EDC) as a component of the CDT project we wanted to do it in the open as much as possible. But we still had quite a bit of initial work to do before the community would be able to evaluate what we were doing. Now that the initial contribution is in CDT we're going to start working on changing our habits to bring more openness and transparency to the effort:

We're going to start moving our discussions about EDC to the cdt-dev mailing list. This may seem simple but we also don't want to bore the CDT community with issues related to Carbide, Symbian, on-device debugging etc. so we'll need to be a little selective.

New issues with EDC will be logged in the Eclipse bugzilla instead of our Carbide bugzilla. We'll need to be a little selective here too and probably won't log every minor issue, but anything that merits any sort of discussion will be public.

Currently our team has two committers on the CDT project, Warren Paul and myself. I've been syncing the EDC sources in CDT with our internal copy. This has done wonders for my committer stats, it looks like I wrote all of the EDC code, but has masked the contributions of our team members. So we're going to start nominating additional people as CDT committers, starting with the ones who already have a track record of contributions to other components in addition to their work on EDC.

Carbide, CDT, EDC Update

Time for an update from our team here at Nokia working on Carbide 3.0, Eclipse CDT 7.0, and the new Eclipse Debugger for C/C++ (EDC):

EDC is now part of the regular CDT build. Many thanks to Doug Schaefer for getting this done. I hadn't done much with the CDT build before and wasn't making much progress, but Doug resolved a couple tricky issues, like pulling the TCF source in from Subversion. We still have a version of EDC in our CVS so the Carbide team can easily commit stuff, but I'm syncing it every few days.

Custom Variable Formatting in EDC: David committed the first phase of support for custom variable formatting. Using a new extension point a plug-in can alter the way data is shown in the Variables view during an EDC debug session. An extension can provide an alternative to the standard structure and content of any variable type.

We intend to provide formatters for some STL, Qt & Symbian data types. Also there are general purpose formatters for arrays and structs:

 
Unformatted C/C++ struct

Formatted C/C++ struct





Debug Snapshot Albums: A new feature in EDC is the ability to capture a snapshot of the state of your debug session for later review. A new Snapshot Album view shows the available albums of snapshots from prior debug sessions and lets you annotate their contents. Snapshot Albums can be launched to show a re-creation of the original debug session. Tim and I have been overhauling some of the initial work and getting the UI far enough along so that we can start usability testing soon. I'll write more about this when the work settles down a bit.

Plug & Play Debug Connectivity: We've made a lot of improvements in usability when starting a debug session on a phone. We started with a detailed analysis of all the options available when connecting to a phone, then narrowed them down into a new launch wizard that can start a debug session in just a few steps. This will make on-device debugging in Carbide a lot easier and I hope to apply some of the lessons learned when we overhaul the launch experience in CDT.

EDC Symbol Reader Overhaul: Ed & Steve are in the midst of an overhaul of the Dwarf reader in EDC. We originally wrote it for completeness and to have something to build the rest of the debugger around, but knew more work was required to get better performance and memory usage. This effort will likely be continuing for the next several weeks.

Community Contributions to EDC: People are starting to review the code, report bugs, and contribute patches. In particular John Cortell at Freescale has been improving the way EDC connects to TCF agents and providing a fresh perspective on everything from naming to API visibility.

That's it for now, I'm diving back into the code...