6

In order to work around an apple bug in xcode 7.3 where xcode blows up when hitting some breakpoints, we need to either turn off CLANG_ENABLE_MODULE_DEBUGGING or stay with xcode 7.2. Turning off CLANG_ENABLE_MODULE_DEBUGGING sounds great.

What does it really mean to not be able to debug CLang modules in a typical iOS developer work environment? How can one know what CLang modules are being depended on either directly or transitively?

Here is a discussion around that blow up issue: https://forums.developer.apple.com/message/126468#126468

Understanding CLang Modules and Debugging Them

Here is an Introduction to Objective-C Modules

From another source titled Apple Releases Xcode 7 Beta:

Clang modules and precompiled headers for C, C++, Objective-C, and Objective-C++ contain debug information for the types they define. When building with the Xcode setting CLANG_ENABLE_MODULE_DEBUGGING=YES (enabled by default), clang stores references to the types

I see a couple of our Cocoa Pods use @import which seems related.

What is a typical example of debug information that we would not see with this off?

finneycanhelp
  • 9,018
  • 12
  • 53
  • 77
  • I cannot find out anywhere online how to turn off CLANG_ENABLE_MODULE_DEBUGGING. Could you please explain how or provide a link? – FateNuller Apr 13 '16 at 01:55
  • I don't recall how through xcode. However, the line is in WHATEVER_YOUR_PROJECT.xcodeproj/project.pbxproj's XCBuildConfiguration section /* Debug */ build settings. For whatever reason, I don't see it through xcode. – finneycanhelp Apr 14 '16 at 10:50

1 Answers1

12

When clang module debugging is turned on, clang generates the debug information for all the types contained in any modules that your code imports each in their own separate section of the debug information, and then all the other debug information can use the types that come from that module by pointing to that module's section in the debug info.

When clang module debugging is turned off, then each compilation unit (.c, .m or .swift file) will get a copy of any types that it uses, and will refer to them locally.

So turning this "on" can reduce the size of the debug information for large projects.

Also, since debug information can get pretty big, in the "off" case, the compiler plays some tricks to keep debug size manageable. For instance, clang only emits used types into the debug information, so if there's a type from some module that nobody in your program uses, you won't get debug information for that type. This isn't a huge problem in general, since if you never use some type in your code you are less likely to use it in your debugging. But it can sometimes cause problems.

It also doesn't emit signature information for functions your program uses but doesn't define. This is why you end up having to cast return types in expressions in the "print" command that you don't have to cast in your code.

OTOH, when it is "on", since the compiler knows it only has to generate this information once, it can be more complete about what it emits.

For Objective C you can work around any missing types/function signatures that come from modules you are using by running:

(lldb) expr @import "FrameworkWhoseTypesOrSignaturesYouWant"

at the beginning of your debug session.

Jim Ingham
  • 25,260
  • 2
  • 55
  • 63