Xcode 9-框架断点 [英] Xcode 9 - Framework breakpoints

问题描述

在Xcode 7和8中，我可以通过在xcworkspace(也包含框架项目)中运行包含的应用程序来调试自己正在开发的框架.如果我在框架中设置断点，则它们将在运行时触发.

In Xcode 7 and 8, I have been able to debug a framework I've been developing by running the containing application within an xcworkspace that also contains the framework project. If I set breakpoints in the framework, they would get triggered at runtime.

在Xcode 9 beta 6中，情况不再如此.到目前为止，在模拟器上调试时，执行仅在框架断点处停止.当我在物理设备上调试时，框架断点不会停止执行，并且看起来它们被完全忽略了.

In Xcode 9 beta 6, this is no longer the case. So far, execution is only stopping at the framework breakpoints when debugging on simulator. When I debug on a physical device, the framework breakpoints do not stop execution and it appears they are completely ignored.

如何才能使框架断点正常工作，以便在Xcode 9中的iOS 11上调试我的框架?

How can I get framework breakpoints to work properly in order to debug my framework on iOS 11 in Xcode 9?

FWIW:xcworkspace是通过在框架根目录中运行pod install创建的.然后，我将示例应用程序的xcodeproj添加到xcworkspace.直到在Xcode 9 beta 6上进行测试之前，该功能一直有效.

FWIW: The xcworkspace was created by running pod install inside the framework root directory. I then added the sample application's xcodeproj to the xcworkspace. This has been functional up until testing on Xcode 9 beta 6.

确认此行为仍在Xcode 9.0的GM种子上发生.

Confirmed that this behavior still takes place on the GM seed of Xcode 9.0.

推荐答案

TL; DR -在调试或准备发行时，我需要更改存档脚本从哪个目录读取.现在进行调试时，如果我希望断点在运行时正常工作，则需要确保将框架方案的存档配置设置为调试".在准备可用于生产的.framework时，我仅使用发布".

TL;DR - I needed to change which directory my archive script reads from when debugging or when preparing a release. Now when debugging, I need to be sure to set my framework scheme's archive config to "Debug" if I want breakpoints to work properly at runtime. I only use "Release" when preparing a production-ready .framework.

我通过错误报告获得了Apple开发人员的支持.我将在下面粘贴响应.当他提到"lipo"时，他指的是我在后归档脚本中进行的调用，该脚本通过模拟器和物理设备构建创建通用框架.

I reached out to Apple developer support via bug report. I will paste the response below. When he mentions "lipo", he is referring to a call I make in a post-archive script that creates a universal framework from the simulator and physical device builds.

Xcode必须将正在运行的二进制文件与仍在计算机上的调试符号进行匹配. Xcode应该自动执行此操作，但是听起来有些东西在Xcode的背后移动了.要了解调试信息是否匹配，可以查看以下命令的输出 (lldb)图像列表 和 /Mac/path/to/Build/Products/Debug-iphoneos％dwarfdump --uuid iOS-App.app/iOS-App 在dylibs上也可以使用.

Xcode has to match up the binary that's running with the debug symbols that are still on your machine. Xcode should do that automatically, but it sounds like some stuff is moved around behind Xcode's back. To know whether the debug information matches you can look at the output of (lldb) image list and /Mac/path/to/Build/Products/Debug-iphoneos% dwarfdump --uuid iOS-App.app/iOS-App that will work on dylibs too.

您的框架的地址周围是否有括号?这是lldb找不到您的符号的肯定标志.

Does your framework have parenthesis around the address? That's a sure sign that lldb can't find your symbols.

如果映像列表中的UUID与dwarfdump不匹配，则说明在可执行文件运行之前已对其进行了修改，并且与您的内置产品不匹配.我们不确定lipo是否可以这样做，我在您的脚本中看到了，但一定会检查.如果debug-info不再存在，则无能为力.

if the UUID in image list doesn't match the dwarfdump, then something has modified the executable before it ran and doesn't match your built products. We’re not sure if lipo might do that, which I see in your script but definitely check. Not much can be done if the debug-info no longer exists.

如果可以在磁盘上找到具有匹配的UUID的正确可执行文件，则只需 (lldb)图片添加/Mac/path/to/DerivedData-asdfasdfadf/Products/Debug-iphoneos/iOS-App.app/Frameworks/Framework

If you can find the right executable with a matching UUID on your disk, you can simply (lldb) image add /Mac/path/to/DerivedData-asdfasdfadf/Products/Debug-iphoneos/iOS-App.app/Frameworks/Framework

此外，Xcode使用Spotlight在您的计算机上查找符号.为避免在构建时不断重新编制索引，将包含.o文件和其他存储调试信息的位置的Intermediates/目录列入了黑名单.这种情况发生在Xcode 9.0的后期，所以这可能是您的东西以前工作的原因.

Additionally, Xcode uses Spotlight to find symbols on your machine. To avoid constantly re-indexing while building, the Intermediates/ directory containing .o files and other place where debug information is stored was blacklisted. This happened fairly late in Xcode 9.0 so may be the reason your stuff was working before.

当我在运行时运行(lldb) image list时，我发现框架的UUID与dwarfdump在/Mac/path/to/Build/Products/Debug-iphoneos处报告的UUID不匹配.

When I ran (lldb) image list at runtime, I saw that the UUID of my framework did not match that which was reported by dwarfdump at /Mac/path/to/Build/Products/Debug-iphoneos.

我最终修改了我的归档后脚本，以更改在创建框架时从哪个构建目录读取.当我将存档配置设置为调试"时，它将立即从Debug-iphoneos中读取.当我将其设置为发布"时，它会从${BUILD_DIR}/${CONFIGURATION}${EFFECTIVE_PLATFORM_NAME}

I ended up modifying my post-archive script to change which build directory it reads from when creating the framework. When I set my archive config to "Debug", it will read from Debug-iphoneos now. When I set it to "Release" it reads from ${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}"

如果路径令人困惑，我不会怪你.本质上，工作空间看起来像:

If the paths are confusing, I don't blame you. Essentially, workspace looks like:

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

这篇关于Xcode 9-框架断点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！