$ dwarfdump --uuid eif-ios-app.app2.0.1.dSYM
UUID: 29FB573E-D9F6-3C75-A0F3-BC1767940073 (armv7) eif-ios-app.app2.0.1.dSYM/Contents/Resources/DWARF/eif-ios-app
UUID: 33BE41CB-612E-3F29-AE4D-40C12AF4BF1C (arm64) eif-ios-app.app2.0.1.dSYM/Contents/Resources/DWARF/eif-ios-app
比对此uuid和crashlog里的uuid是否匹配，匹配则继续
$ dwarfdump --arch arm64 --lookup 0x1000ff4d0 eif-ios-app.app2.0.1.dSYM（此处arch必须和crash log的arch对应）
或：
$ atos -arch
例如：
$ atos -arch armv7 -o /Users/hengda/Downloads/eif-ios-app.app2.0.1.dSYM/Contents/Resources/DWARF/eif-ios-app -l 0x4000 0x3ddb8b
输出中的如下内容即为要找的符号：
Line table file: 'HomeViewController.m' line 163, column 5 with start address 0x00000001000ff4bc
补充：
一、错误报告中的三种地址：
stack address
load address
symbol address
1）stack address
同意词：runtime address
从操作系统的堆栈0点算起，
2）load address
同意词或近意词：base address, slide address,start address
应用堆栈在操作系统堆栈中的起点。
3）symbol address
同意词：relative address
以load address为起点算起的偏移量。
注意：在崩溃报告中，此值为stack address - load address。
在dSYM文件中，一般设定load address为0x4000，这个值可用otool查。
所以在用symbol address在dSYM文件中查找对应的symbol时，需要 加 0x4000。
二、两种格式的崩溃报告：
1、
appname 0x97525 appname + 615717
2、
appname 0x97525 0x29000 + 615717
两种格式的对比：
app name 0x97525（stack address） appname + 615717 (symbol address)
appname 0x97525（stack address） 0x29000(load address) + 615717(symbol address)
一定注意计算时进制转换：symbol address是10进制，其它两个是16进制，以0x开头。
两种格式的区别就是第一种比第二种少了load address。
三、
三个地址间的运算关系：
symbol_address = stack_address - load_address
由此可以推算出：
load_address = stack_address - symbol_address
四、由地址得到symbol的命令：
命令行中的地址都必须转为16进制。
1、atos -o appname.app.dSYM/Contents/Resources/DWARF/appname -arch armv7 symbol_address + 0x4000
3、atos -o MyApp.app/MyApp -arch armv7 -l stack_address load_address
2、dwarfdump -arch armv7 appname.app.dSYM --lookup symbol_address + 0x4000