Xcode 9 - Framework Breakpoints

Question

In Xcode 7 und 8 konnte ich ein Framework debuggen, das ich entwickelt habe, indem ich die enthaltene Anwendung in einem xcworkspace ausgeführt habe, der auch das Framework-Projekt enthält. Wenn ich Haltepunkte im Framework setze, würden sie zur Laufzeit ausgelöst werden.

In Xcode 9 Beta 6 ist dies nicht mehr der Fall. Bisher stoppt die Ausführung nur beim Debuggen im Simulator an den Framework-Breakpoints. Wenn ich auf einem physischen Gerät debugge, unterbrechen die Framework-Haltepunkte die Ausführung nicht und es scheint, dass sie vollständig ignoriert werden.

Wie kann ich Framework Breakpoints richtig funktionieren lassen, um mein Framework auf iOS 11 in Xcode 9 zu debuggen?

FWIW: Der xcworkspace wurde erstellt, indem pod install im Framework-Stammverzeichnis ausgeführt wurde. Ich habe dann die xcodproj von der Beispielanwendung zum xcworkspace hinzugefügt. Dies wurde bis zum Testen auf Xcode 9 Beta 6 funktionell.

Edit: Bestätigt, dass dieses Verhalten noch auf dem GM-Seed von Xcode 9.0 stattfindet.

Answer 1

TL; DR - Ich musste ändern, in welches Verzeichnis mein Archivskript beim Debuggen oder beim Vorbereiten einer Version liest. Beim Debuggen muss ich jetzt sicherstellen, dass die Archivkonfiguration meines Framework-Schemas auf "Debug" eingestellt ist, wenn Breakpoints zur Laufzeit korrekt funktionieren sollen. Ich verwende "Release" nur, wenn ein produktionsfertiges .framework vorbereitet wird.

Ich erreichte Apple-Entwickler-Support über Fehlerbericht. Ich werde die Antwort unten einfügen. Wenn er "Lipo" erwähnt, bezieht er sich auf einen Aufruf, den ich in einem Post-Archiv-Skript mache, das ein universelles Framework aus dem Simulator und den physischen Geräte-Builds erzeugt.

Xcode muss die Binärdatei abgleichen, die mit den Debugsymbolen ausgeführt wird, die sich noch auf Ihrem Computer befinden.Xcode sollte das automatisch tun, aber es hört sich so an, als würden einige Sachen hinter Xcode's Rücken herum bewegt. Um zu wissen, ob die Debug-Informationen übereinstimmen, können Sie die Ausgabe von (lldb) Bildliste und /Mac/Pfad/zu/Build/Produkte/Debug-iphoneos% dwarfdump --uuid iOS-App.app/iOS- App , die auch auf dylibs funktioniert.

Hat Ihr Framework Klammern um die Adresse? Das ist ein sicheres Zeichen, dass lldb deine Symbole nicht finden kann.

Wenn die UUID in der Bildliste nicht mit dem dwarfdump übereinstimmt, hat etwas die ausführbare Datei geändert, bevor sie ausgeführt wurde und nicht mit Ihren erstellten Produkten übereinstimmt. Wir sind nicht sicher, ob Lipo das tun könnte, was ich in deinem Skript sehe, aber überprüfe es auf jeden Fall. Es kann nicht viel getan werden, wenn die Debug-Info nicht mehr existiert.

Wenn Sie die richtige ausführbare Datei mit einem entsprechenden UUID auf Ihrer Festplatte finden können, können Sie einfach (LLDB) Bild hinzufügen /Mac/path/to/DerivedData-asdfasdfadf/Products/Debug-iphoneos/iOS-App.app/Frameworks/Framework

Darüber hinaus verwendet Xcode Spotlight, um Symbole auf Ihrem Computer zu finden. Um eine ständige Neuindizierung während des Erstellens zu vermeiden, wurde das Intermediates/-Verzeichnis, das .o-Dateien enthält, und ein anderer Ort, an dem Debug-Informationen gespeichert sind, auf die schwarze Liste gesetzt. Dies ist relativ spät in Xcode 9.0 passiert, also könnte der Grund dafür sein, dass deine Sachen früher funktionierten.

Als ich (lldb) image list zur Laufzeit lief, sah ich, dass der UUID meines Rahmen, dass nicht übereinstimmten, die von dwarfdump bei /Mac/path/to/Build/Products/Debug-iphoneos berichtet wurden.

Am Ende habe ich mein Post-Archiv-Skript geändert, um zu ändern, welches Build-Verzeichnis es beim Erstellen des Frameworks liest. Wenn ich meine Archivkonfiguration auf "Debug" setze, wird es jetzt von Debug-iphoneos gelesen. Wenn ich es auf „Release“ heißt es aus ${BUILD_DIR}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}

# NOTE: This script creates a universal framework (device and simulator). However, *** for this to work: a Simulator target must be built first, and then Archive on the Device *** 

BUILD_PRODUCTS="${SYMROOT}/../../../../Products" 
SIM_PATH="${BUILD_PRODUCTS}/Debug-iphonesimulator/${TARGET_NAME}.framework" 
if [ "${CONFIGURATION}" = "Debug" ]; then 
DEV_PATH="${BUILD_PRODUCTS}/Debug-iphoneos/${TARGET_NAME}.framework" 
elif [ "${CONFIGURATION}" = "Release" ]; then 
DEV_PATH="${BUILD_DIR}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}/${TARGET_NAME}.framework" 
fi 
DEST_PATH="${PROJECT_DIR}/../Frameworks/${TARGET_NAME}.framework" 

rm -rf "${DEST_PATH}" 
mkdir "${DEST_PATH}" 
cp -r "${DEV_PATH}/" "${DEST_PATH}/" 
rm -f "${DEST_PATH}/${TARGET_NAME}" 
cp -Rn "${SIM_PATH}/Modules/" "${DEST_PATH}/Modules/" 

lipo -create "${SIM_PATH}/${TARGET_NAME}" "${DEV_PATH}/${TARGET_NAME}" -output "${DEST_PATH}/${TARGET_NAME}" 

Wenn die Pfade sind verwirrend, ich Ihnen nicht verdenken. Im Wesentlichen sieht der Arbeitsbereich folgendermaßen aus:

RootDirectory 
|__SampleApp 
    |__SampleApp.xcodeproj 
|__Frameworks 
    |__MyFramework.framework 
    |__AnotherFramework.framework 
|__MyFramework 
    |__MyFramework.xcworkspace 
    |__MyFramework.xcodeproj 
    |__Podfile (etc..) 

Answer 2

Mein Szenario ist:

ich meinen Rahmen in anderen Weg haben. Normalerweise bekomme ich .framework wenn ich es baue. Und dann füge ich die Framework-Datei (MyFramework.framework) in mein Projekt ein.

Mein Vorschlag ist:

1. einen neuen Haltepunkt vor dem Rahmen Anruf hinzufügen. wie dies

2. Drücken Sie diesen Step Into Taste, wenn die Programmausführung den Haltepunkt erreicht.

Jetzt wird die Ausführung des Gerüsts Source-Bereich gehen, in diesem Punkt, den Sie New Haltepunkte wo immer Sie in Ihrem Rahmen hinzufügen möchten haben.

Dies ist eine funktionierende Lösung in Xcode 9 und iOS 11. Ich hoffe, das hilft Ihnen. Viel Glück.