$ 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 <Binary Architecture>?-o <Path To DSYM File>/Contents/Resources/DWARF/<binary image name> -l <load address> <stack address／address to symbolicate>?
例如：
$ 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
