如何通过MetricKit日志去定位问题代码

假设有如下日志
"crashDiagnostics": [ { "version": "1.0.0", "callStackTree": { "callStacks": [ { "threadAttributed": true, "callStackRootFrames": [ { "binaryUUID": "DC2EACEA-3D9C-3409-96C2-2DF9C89AD19D", "offsetIntoBinaryTextSegment": 6917586944, "sampleCount": 1, "subFrames": [ { "binaryUUID": "DC2EACEA-3D9C-3409-96C2-2DF9C89AD19D", "offsetIntoBinaryTextSegment": 6917586944, "sampleCount": 1, "subFrames": [ { "binaryUUID": "DC2EACEA-3D9C-3409-96C2-2DF9C89AD19D", "offsetIntoBinaryTextSegment": 6917586944, "sampleCount": 1, "subFrames": [ { "binaryUUID": "35463E49-9534-3644-B993-2A73C287A143", "offsetIntoBinaryTextSegment": 4329963520, "sampleCount": 1, "binaryName": "demo", "address": 4333717704 }]

那么我们可以通过atos来定位其代码所在

atos -arch arm64 -o <filePath> -l 0x1 0x102160002

其中0x102160001是offsetIntoBinaryTextSegment+1的十六进制值。之所以使用 -l 0x1，这是因为我们不知道二进制加载地址，或者操作系统在将二进制文件加载到内存中时使用的偏移。通过添加0x1，这使我们可以使用 atos -l 选项应用一个虚构的偏移，以便于符号化而不需要使用其他工具来确定我们需要用于符号化的正确地址。这也是为什么offsetIntoBinaryTextSegment需要加1的原因。
同样的，在这个例子中如果-l 0x2, 即虚拟偏移是2，则定位代码的地址则应该是offsetIntoBinaryTextSegment+2.
参考：https://developer.apple.com/forums/thread/681967