➠更多技術干貨請戳：聽雲博客
序言
怎麼在linux 平台下實現一個類似於mac 平台下的 atos 工具（ iOS 符號化解析)?
分析問題
在github上找到了幾年前的開源實現,[https://github.com/dechaoqiu/atosl](https://github.com/dechaoqiu/atosl)
編譯出來的atosl工具平常很大幾率是工作正常的，只有在特殊情況下會出現解析錯誤,主要表現為以下方式：
1、使用Swift 編寫的app ，編譯出來的 atosl 一定會解析錯誤(亂碼形式)
2、使用C+ + 實現的一些函數，編譯出來的 atosl 解析出來的字符串也是亂碼
3、在解析 iOS 系統framwork 框架的時候 有幾率會出現解析錯誤(亂碼形式)
4、用戶的某些崩潰信息不能定位到具體的 line no，編譯出來的 atosl服務只能解析出來offset。
iOS dSYM 文件結構剖析
在 iOS App 開發過程中，我們會利用Xcode打包,生成.xarchive的包文件，通過Xcode 的Organizer 工具可以管理並導出發布文件，iOS 開發者對這些過程都是輕車熟路，這裡不再重復闡述，主要想講的是,打包之後生成的dSYM 文件。
dSYM 是一個目錄，打開之後，我們會找到一個二進制文件如下圖
可以看出iOS 使用的是DWARF文件結構 （Debug With Attributed RecordFormats） 是一種調試文件結構標准，結構相當復雜。
[https://www.prevanders.net/dwarf.html](https://www.prevanders.net/dwarf.html)
dSYM 文件的一個重要作用就在於，當我們的程序發生崩潰，通過crash log 或其他方式 ，會看到調用棧信息。 通過log信息，我們並不知道具體是在哪一個文件的哪一個位置出了問題， 這個時候這個二進制文件提供的信息就非常有用了，通過它我們可以通過工具 去符號化， Mac OS X 平台下 Xcode 自帶了 atos 這樣的工具，這樣可以直接定位到某個文件的具體位置。 用法如下：
在 Mac OS 下有 dwarfdump 工具來解析DWARF文件，很顯然解析出來的信息並不能滿足我們的所有需求。
dwarfdump -a SwfitTest
如果要了解其內部結構，請參考《iOS系統分析（二）Mach-O二進制文件解析》。
思路
github 下載 atosl 源代碼，C寫的
添加Cxx 與 Swift的錯誤樣例
make test 結果如下，很明顯 Cxx 與 Swift 符號化有問題，這就是我要解決的問題。
返回到mac os x中利用xcode 提供的 xcrun atos 處理，能夠正確解析，（所以我要做的事情就是在linux平台下實現一個 類似於mac os x 平台下的 atos -\>輸入輸出相同）
解決C+ + 亂碼的思考過程，在前面學習分析 Mach-O 文件的時候 使用過一個 MachOView 工具，然後我用工具打開QuartzCore 這個dSYM 文件，發現在 SymTables 裡面解析出來的 字符串也是亂碼，但是神奇的事情發生了，當我鼠標停留在某一行亂碼的時候 復出了正確的解析字符串，這說明 MachOView 是能夠正確解析C + + 名字的。果斷 github 搜源代碼. 從這裡知道了 編譯器在編譯過程中會對函數做一些手腳，下面分析編譯器的行為。
mangled symbol names (重整符號名稱)
C/Cxx
在C這樣的語言中,任何給定的名字(符號)只能對應唯一的一個函數或數據,不需要名字重整(name mangling)。即便如此,如果你看一個典型的純C二進制的符號表,你會發現每個函數名有一個 (下劃線)的前綴，如下：
這種簡單的“mangling”（重整）已有很長的歷史,實際上沒有多少用處,但仍為兼容性和一致性起到一些效果。按照慣例,C中定義的名字會有下劃線,而純匯編定義的全局符號則沒有(盡管許多匯編語言的作者為了一致性，也會預先考慮下劃線的定義)。
Objective-C
它的符號名字不會有異議或者說沖突；Objective-C的方法實現的形式是: -[class selector](#),並且objective - c不允許相同的類使用不同的參數來重載相同的selectors。
Cxx
一個沒有額外信息的簡單的名字可能會產生異議，所以必須做一些處理, 如下：
因為function對應兩個包含不同參數的函數，這在cxx中是合法的定義,所以我們不能簡單地生成兩個\_ function符號,因為鏈接器會不知道如何鏈接，無法區分不同的函數實現。因此,cxx編譯器使用一組嚴格的編碼規則“mangles”(重整)了符號。
Swift
1. 最開始的字符’-‘對Swift符號是必須的
2. ‘-T’是Swift全局符號的標記
解決方法
按照這個規則自己去還原符號也是可行的，不過還是比較費時，還可能有bug。
幸好Xcode 自帶了個工具， 可以查看這些 mangled name 的本來面目，就不需要自己重新去實現.
解決思路過程
既然apple 提供了工具，那麼我就不需要去自己寫了，直接調用即可，在xcode的目錄中找到了工具地址如下：
第一種解決方法 ：管道通信 atosl 直接調用 swift-demangle 。
第二種解決方法 ： 將swift-demangle.dylib 鏈接到程序中。
正確解析。接下來要想辦法將這個小程序移植到Linux 平台下。
我猜這是Swift提供的工具，Google 發現Swift是源代碼級別開源，果然支持Linux。
在linux上編譯 Swift
配置環境編譯之（Ubuntu 14.04），編譯過程中有坑（內存必須配置5GB以上，硬盤30GB 以上）
warning：如果你遇到類似 clang: error: unable to execute command: Killed 的報錯，不要多想，就是內存爆了，多試幾次也許就成功了。
如果一切正常1小時就能編譯完畢（我的硬件環境 MacBookAir 1.4GHz CPU 8GB 內存 固態硬盤，用了將近1個小時）。
第一種解決方案：swift編譯完成後 在build/xxx/xxx/xxx/bin 下果然有ELF這個可執行文件
第二種解決方案： 使用編譯出來的庫文件
在lib目錄下 沒有找到 .so動態庫，納悶很久（swift的 編譯腳本使用的是Cmake） Darwin 這個術語是指 mac 系統內核核心 （包括 xnu kernel 與 Unix Shell 環境），注釋掉這裡就可以將（Linux 共享庫） .so 編譯出來，如果要編譯靜態庫 則需要修改cmake腳本，如下圖：
共享庫編譯出來了，則直接動態鏈接到 atosl中，swift 只能在Ubutun上編譯，如果最終你的atosl 要在 Linux的其他發行版上運行，最好將所有的依賴庫用靜態鏈接。
2
make test
測試發現 cxx 與Swift的測試樣例 的 offset（定位到的 line no 解析不出來），github上的代碼已經很久沒有人維護了，最後還是果斷重寫之。
end
（有任何問題請聯系 email：[email protected]）
原文鏈接：http://blog.tingyun.com/web/article/detail/1342
http://xxxxxx/Linuxjc/1173308.html TechArticle