Disabling CLANG_ENABLE_MODULE_DEBUGGING consequences

To get around Apple's bug in xcode 7.3, where xcode explodes when it hits some breakpoints, we need to either disable CLANG_ENABLE_MODULE_DEBUGGING or stay with xcode 7.2. Disabling CLANG_ENABLE_MODULE_DEBUGGING sounds great.

What does it really mean to not be able to debug CLang modules in a typical iOS developer workspace? How do I know which CLAN modules are direct or transit dependent?

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

Overview of CLang Modules and Debugging

Here is an Introduction to Objective-C Modules

From another source called Apple, it released the beta version of Xcode 7 :

Clang modules and precompiled headers for C, C ++, Objective-C and Objective-C ++ contain debugging information for the types that they define. When creating with Xcode setup CLANG_ENABLE_MODULE_DEBUGGING = YES (enabled by default), clang stores type references

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

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

+5
source share
1 answer

When the debug function of the clang module is enabled, clang generates debug information for all types contained in any modules that your code imports each in its own section of debug information, and then all other debug information can use the types that come from this module, pointing to this section of the module is in debugging information.

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

Therefore, enabling this "on" can reduce the size of debugging information for large projects.

In addition, since debugging information can be quite large, in the case of "off", the compiler performs some tricks to keep the debugging size manageable. For example, clang only emits used types into debugging information, so if there is a type from some module that no one in your program uses, you will not get debugging information for this type. This is not a big problem in general, because if you never use any type in your code, you are unlikely to use it in your debugging. But sometimes it can cause problems.

It also does not generate signature information for functions that your program uses, but does not define. That's why you have to throw return types into expressions in the "print" command that you don't need to do in your code.

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

For Objective-C, you can work around any missing function types / signatures that come from the modules you use by running:

(lldb) expr @import "FrameworkWhoseTypesOrSignaturesYouWant" 

at the beginning of a debugging session.

+5
source

Source: https://habr.com/ru/post/1245918/


All Articles