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.
