原文出自【听云技术博客】：http://blog.tingyun.com/web/article/detail/1342
序言
怎么在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：liutianshxkernel@gmail.com）