UPDATED: Filed a bug on this issue for any Apple folks reading this at rdar://problem/7590305.
Recently, at The Department, we experienced some problems debugging an iPhone 3.1.2 application written in a mix of Objective-C and C++ in Xcode (or the raw gdb console for that matter).
The symptoms were that while the app would run and we could set and hit breakpoints, attempting to browse locals or “p” or “po” in gdb while in a breakpoint would just report total garbage.
The app in question is split across multiple static libraries in multiple Xcode project files. To complicate things even more, there are multiple targets for different platforms in the various projects (iPhone, simulator, Mac OS).
Initially, it seemed like maybe the problem was relating to the multi-target, multi-platform project structure. It was certainly not easy to coax all these targets and platforms into the various projects, and is not a generally not recommended practice in the first place, but boy is it convenient!
Luckily we found we could reproduce the same debugging problem in a simple test application. To replicate, we just created a fresh project using iPhone OS “Application” template called “Window-based Application”. We just added two simple classes, one C++ and one Objective-C class, each with a handful of member variables. Next we added instances of those two classes as member of the AppDelegate Objective-C class generated by Xcode. Set a breakpoint and run on the target device in the AppDelegate’s initializer and boom! Garbage locals.
The weird part is that reproducing the same steps using the iPhone OS “Application” template called “OpenGL ES Application” worked fine. No garbage locals when debugging.
Using trusty Araxis merge to compare the two project files, we spotted one minor difference in the two Xcode generated projects. The line:
"GCC_THUMB_SUPPORT[arch=armv6]" = "";
was present in the project that we could see locals for, but not in the one that resulted in garbage locals in the debugger.
After adding this line into the non-working project, everything worked great in the debugger. No problem seeing locals.
Weirdly try as we might, we were not able to figure out a way to get the Xcode user interface to add this line to our bugged out (but Xcode generated) project. And similarly, we were not able to figure out how a way to get the Xcode user interface to removed this line from a working project. It seems this line needs to be added in by hand in the project XML (or appear in Apple’s project template in the first place).
Happily, we added this line to all our various Xcode targets and projects in our complex app and…everything now works great!
Mind filing a bug on that? Thanks!
http://bugreporter.apple.com I believe.
Uncheck the “”Compile for Thumb” in your project. This is what adding the ‘”GCC_THUMB_SUPPORT[arch=armv6]” = “”‘ line to your project will end up doing.
Hi Greg,
Thanks for the tip! Flipping that option in my Xcode doesn’t actually generate the same line in the project, but it does achieve the same result. When I flip that check box, I get:
GCC_THUMB_SUPPORT = NO;
Which seems to have the same effect as:
“GCC_THUMB_SUPPORT[arch=armv6]” =”"
It’s probably neither here nor there, but there is a bit of a graphical difference in the two settings in Xcode. In the GL ES template (with the parameterized define) the GUI looks like this:
Initially confusing because it looks like Thumb support is enabled but debugging works.
Either way, as you point out, toggling it off has the same effect as adding in the parameterized enable line by hand; it enables debugging!
Yay!
$author, great information! Learnt a lot from it….