disattivazione delle conseguenze CLANG_ENABLE_MODULE_DEBUGGING

Question

Per ovviare a un bug di mela in xcode 7.3 dove xcode esplode quando si verificano alcuni punti di interruzione, è necessario disattivare CLANG_ENABLE_MODULE_DEBUGGING o rimanere con xcode 7.2. Disattivare CLANG_ENABLE_MODULE_DEBUGGING sembra ottimo.

Che cosa significa in realtà non poter eseguire il debug dei moduli CLang in un tipico ambiente di lavoro degli sviluppatori iOS? Come si può sapere quali moduli CLang dipendono direttamente o in modo transitorio?

Ecco una discussione intorno a quel esplodere problema: https://forums.developer.apple.com/message/126468#126468

Capire Moduli clang e debug di Loro

Ecco un Introduction to Objective-C Modules

da un'altra fonte dal titolo Apple Releases Xcode 7 Beta:

Moduli Clang e intestazioni precompilate per C, C++, Objective-C e Objective-C++ contiene informazioni di debug per i tipi che definiscono. Quando si costruisce con l'impostazione CLANG_ENABLE_MODULE_DEBUGGING Xcode = YES (abilitato per default), memorizza Clang riferimenti ai tipi

vedo un paio di nostri cabosse usare @import che sembra correlato.

Che cosa è un tipico esempio di informazioni di debug che non si vedrebbero in questo modo?

Answer 1

Quando il debug del modulo clang è attivato, clang genera le informazioni di debug per tutti i tipi contenuti in tutti i moduli che il codice importa ciascuno nella propria sezione separata delle informazioni di debug e quindi tutte le altre informazioni di debug possono utilizzare il tipi che provengono da quel modulo puntando alla sezione di quel modulo nelle informazioni di debug.

Quando il debug del modulo clang è disattivato, ciascuna unità di compilazione (file .c, .m o .swift) otterrà una copia di qualsiasi tipo che utilizza e farà riferimento a loro localmente.

Pertanto, l'attivazione di questo "on" può ridurre la dimensione delle informazioni di debug per progetti di grandi dimensioni.

Inoltre, poiché le informazioni di debug possono diventare piuttosto grandi, nel caso "off", il compilatore svolge alcuni trucchi per mantenere gestibile la dimensione del debug. Ad esempio, clang emette solo i tipi usati nelle informazioni di debug, quindi se c'è un tipo da qualche modulo che nessuno nel tuo programma usa, non otterrai informazioni di debug per quel tipo. Questo non è un problema enorme in generale, dal momento che se non si utilizza mai del codice nel proprio codice, è meno probabile utilizzarlo nel debug. Ma a volte può causare problemi.

Inoltre, non emette informazioni sulla firma per le funzioni utilizzate dal programma ma non definite. Questo è il motivo per cui si finisce per dover eseguire il cast dei tipi restituiti nelle espressioni nel comando "print" che non è necessario eseguire il cast nel proprio codice.

OTOH, quando è "on", poiché il compilatore sa che deve solo generare queste informazioni una volta, può essere più completo su ciò che emette.

Per Objective C è possibile aggirare eventuali firme tipi/funzioni mancanti che provengono dai moduli in uso eseguendo:

(lldb) expr @import "FrameworkWhoseTypesOrSignaturesYouWant" 

all'inizio della sessione di debug.