Thursday, June 17, 2010

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.

5 comments:

tlandry said...

Hello Ken,
A couple of questions...
1) when is the 3.0 version expected to be released?
2) what Eclipse version is 3.0 based on?
3) you referred to version 2.6...is that the most recent version? If so, what Eclipse version is that based on?
Thanks.
Todd

Ken Ryall said...

C3 will be out around the end of September but you will be able to join the beta program if you want to try it sooner. It is based on Eclipse 3.6 (Helios). Version 2.6 is the latest shipping, it is based on Eclipse 3.5.2.

pkures said...

How do I join the beta program ? I've been part of beta since Carbide.C++ 1.x, but I don't know where to find 3.0 beta group. I'am a developer of quite large C++ project and we are having lot of issues with the current version (2.4) Perhaps you could point me in the right direction.?

Ken Ryall said...

We are just now putting together the 3.0 beta group for internal Nokia users and will make it available externally soon. Currently the 3.0 beta builds only target pre-production phones used internally at Nokia, but we will soon have a debug agent that you can use on a production phone.

S60 said...

Hello!
Six months ago after the expected date of release... When the Carbide.c++ 3.0 will be released and will it have support a debugging apps over IP? (AppTRK in 2.7 supports USB and bluetooth connections, and works over COM ports).