xcrun atos -o MiniFamilySchool.app.dSYM/Contents/Resources/DWARF/MiniFamilySchool -arch armv7 -l 0x100034000 0x0000000100769c3c

在前面的内容可以知道，符号表的作用是把崩溃中的函数地址解析为函数名等信息。

如果开发者能够获取到崩溃的函数地址信息，就可以利用符号表分析出具体的出错位置。

Xcode提供了几个工具来帮助开发者执行函数地址符号化的操作。

例如，崩溃问题的函数地址堆栈如下：

错误地址堆栈

3  CoreFoundation           0x254b5949 0x253aa000 + 1096008
4  CoreFoundation           0x253e6b68 _CF_forwarding_prep_0 + 24
5  SuperSDKTest             0x0010143b 0x000ef000 + 74808

符号化堆栈

3   CoreFoundation          0x254b5949 <redacted> + 712
4   CoreFoundation          0x253e6b68 _CF_forwarding_prep_0 + 24
5   SuperSDKTest            0x0010143b -[ViewController didTriggerClick:] + 58

说明：

大部分情况下，开发者能获取到的都是错误地址堆栈，需要利用符号表进一步符号化才能分析定位问题。

部分情况下，开发者也可以利用backtrace看到符号化堆栈，可以大概定位出错的函数、但却不知道具体的位置。通过利用符号表信息，也是可以进一步得到具体的出错位置的。

目前，许多崩溃监控服务都显示backtrace符号化堆栈，增加了可读性，但分析定位问题时，仍然要进一步符号化处理。

崩溃信息的UUID

0xef000 - 0x17efff SuperSDKTest armv7 <38d66f9734ca3843a2bf628bb9015a8b> /var/mobile/.../SuperSDKTest.app/SuperSDKTest
下面，利用两个工具来进行一下符号化的尝试：

1、symbolicatecrash

symbolicatecrash是一个将堆栈地址符号化的脚本，输入参数是苹果官方格式的崩溃日志及本地的.dSYM文件，执行方式如下：

$ symbolicatecrash XX.crash [XX.app.dSYM] > xx.sym.crash# 如果输入.dSYM参数，将只解析系统库对应的符号
使用symbolicatecrash工具的限制就在于只能分析官方格式的崩溃日志，需要从具体的设备中导出，获取和操作都不是很方便，而且，符号化的结果也是没有具体的行号信息的，也经常会出现符号化失败的情况。
实际上Xcode的Organizer内置了symbolicatecrash工具，所以开发者才可以直接看到符号化的错误日志。

2、atos

更普遍的情况是，开发者能获取到错误堆栈信息，而使用atos工具就是把地址对应的具体符号信息找到。

atos实际是一个可以把地址转换为函数名（包括行号）的工具，它的执行方式如下：

$ xcrun atos -o executable -arch architecture -l loadAddress
address ...
说明：

loadAddress 表示函数的动态加载地址，对应崩溃地址堆栈中 + 号前面的地址，即0x000ef000

address 表示运行时地址、对应崩溃地址堆栈中第一个地址，即0x0010143b

实际上，崩溃地址堆栈中+号前后的地址相加即是运行时地址，即0x000ef000 + 74808 = 0x0010143b

执行命令查询地址的符号，可以看到如下结果：

$ xcrun atos -o SuperSDKTest.app.dSYM/Contents/Resources/DWARF/SuperSDKTest -arch armv7 -l 0x000ef000
0x0010143b
-[ViewController didTriggerClick:] (in SuperSDKTest) (ViewController.m:35)
开发者在具体的运用中，是可以通过编写一个脚本来实现符号化错误地址堆栈的。