在linux平臺實現atosl

聽雲APM發表於2016-11-17

Linux

原文出自【聽雲技術部落格】：http://blog.tingyun.com/web/article/detail/1342

序言

怎麼在linux 平臺下實現一個類似於mac 平臺下的 atos 工具（ iOS 符號化解析)?

分析問題

在github上找到了幾年前的開源實現,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 檔案。

enter image description here

dSYM 是一個目錄，開啟之後，我們會找到一個二進位制檔案如下圖

enter image description here

可以看出iOS 使用的是DWARF檔案結構（Debug With Attributed RecordFormats）是一種除錯檔案結構標準，結構相當複雜。

https://www.prevanders.net/dwarf.html

dSYM 檔案的一個重要作用就在於，當我們的程式發生崩潰，通過crash log 或其他方式，會看到呼叫棧資訊。通過log資訊，我們並不知道具體是在哪一個檔案的哪一個位置出了問題，這個時候這個二進位制檔案提供的資訊就非常有用了，通過它我們可以通過工具去符號化， Mac OS X 平臺下 Xcode 自帶了 atos 這樣的工具，這樣可以直接定位到某個檔案的具體位置。用法如下：

enter image description here

在 Mac OS 下有 dwarfdump 工具來解析DWARF檔案，很顯然解析出來的資訊並不能滿足我們的所有需求。

dwarfdump -a  SwfitTest

enter image description here

如果要了解其內部結構，請參考《iOS系統分析（二）Mach-O二進位制檔案解析》。

思路

github 下載 atosl 原始碼，C寫的

enter image description here

新增Cxx 與 Swift的錯誤樣例

enter image description here

make test 結果如下，很明顯 Cxx 與 Swift 符號化有問題，這就是我要解決的問題。

enter image description here

返回到mac os x中利用xcode 提供的 xcrun atos 處理，能夠正確解析，（所以我要做的事情就是在linux平臺下實現一個類似於mac os x 平臺下的 atos ->輸入輸出相同）

enter image description here

解決C+ + 亂碼的思考過程，在前面學習分析 Mach-O 檔案的時候使用過一個 MachOView 工具，然後我用工具開啟QuartzCore 這個dSYM 檔案，發現在 SymTables 裡面解析出來的字串也是亂碼，但是神奇的事情發生了，當我滑鼠停留在某一行亂碼的時候復出了正確的解析字串，這說明 MachOView 是能夠正確解析C + + 名字的。果斷 github 搜原始碼. 從這裡知道了編譯器在編譯過程中會對函式做一些手腳，下面分析編譯器的行為。

enter image description here

mangled symbol names (重整符號名稱)

C/Cxx

在C這樣的語言中,任何給定的名字(符號)只能對應唯一的一個函式或資料,不需要名字重整(name mangling)。即便如此,如果你看一個典型的純C二進位制的符號表,你會發現每個函式名有一個 (下劃線)的字首，如下：

enter image description here

這種簡單的“mangling”（重整）已有很長的歷史,實際上沒有多少用處,但仍為相容性和一致性起到一些效果。按照慣例,C中定義的名字會有下劃線,而純彙編定義的全域性符號則沒有(儘管許多組合語言的作者為了一致性，也會預先考慮下劃線的定義)。　　　　

Objective-C

它的符號名字不會有異議或者說衝突；Objective-C的方法實現的形式是: -class selector,並且objective - c不允許相同的類使用不同的引數來過載相同的selectors。

Cxx

一個沒有額外資訊的簡單的名字可能會產生異議，所以必須做一些處理, 如下：

enter image description here

因為function對應兩個包含不同引數的函式，這在cxx中是合法的定義,所以我們不能簡單地生成兩個_ function符號,因為連結器會不知道如何連結，無法區分不同的函式實現。因此,cxx編譯器使用一組嚴格的編碼規則“mangles”(重整)了符號。

Swift

enter image description here

最開始的字元’-‘對Swift符號是必須的 ‘-T’是Swift全域性符號的標記 解決方法

按照這個規則自己去還原符號也是可行的，不過還是比較費時，還可能有bug。

幸好Xcode 自帶了個工具，可以檢視這些 mangled name 的本來面目，就不需要自己重新去實現.

解決思路過程

既然apple 提供了工具，那麼我就不需要去自己寫了，直接呼叫即可，在xcode的目錄中找到了工具地址如下：

enter image description here

第一種解決方法：管道通訊 atosl 直接呼叫 swift-demangle 。

第二種解決方法：將swift-demangle.dylib 連結到程式中。

enter image description here

正確解析。接下來要想辦法將這個小程式移植到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這個可執行檔案

enter image description here

第二種解決方案：使用編譯出來的庫檔案

在lib目錄下沒有找到 .so動態庫，納悶很久（swift的編譯指令碼使用的是Cmake） Darwin 這個術語是指 mac 系統核心核心（包括 xnu kernel 與 Unix Shell 環境），註釋掉這裡就可以將（Linux 共享庫） .so 編譯出來，如果要編譯靜態庫則需要修改cmake指令碼，如下圖：

enter image description here