编译过程

基本的编译过程分为四个步骤:

  1. 预处理(Pre-process):把宏替换,删除注释,展开头文件,产生 .i 文件。

  2. 编译(Compliling):把之前的 .i 文件转换成汇编语言,产生 .s文件。

  3. 汇编(Asembly):把汇编语言文件转换为机器码文件,产生 .o 文件。

  4. 链接(Link):对.o文件中的对于其他的库的引用的地方进行引用,生成最后的可执行文件(同时也包括多个 .o 文件进行 link)。

然后通过解析 xcode 编译 log,可以发现 xcode 是根据 target 分开进行编译的。每个 target 的具体的编译过程也可以通过展开 log 日志获得。基本的格式就是首先简明一句说明要干什么,然后缩进的几行说明具体的操作。比如:

(1) ProcessPCH /.../Pods-SSZipArchive-prefix.pch.pch Pods-SSZipArchive-prefix.pch normal armv7 objective-c com.apple.compilers.llvm.clang.1_0.compiler
    (2) cd /.../Dev/objcio/Pods
        setenv LANG en_US.US-ASCII
        setenv PATH "..."
    (3) /.../Xcode.app/.../clang 
            (4) -x objective-c-header 
            (5) -arch armv7 
            ... configuration and warning flags ...
            (6) -DDEBUG=1 -DCOCOAPODS=1 
            ... include paths and more ...
            (7) -c 
            (8) /.../Pods-SSZipArchive-prefix.pch 
            (9) -o /.../Pods-SSZipArchive-prefix.pch.pch

 

就是在处理 pch 头文件,首先切换到 pch 的目录下,然后设置环境变量,然后启动 clang 并进行一系列的配置。在这之后一般就会产生具体的 .o文件作为产出(一般是有多个,针对不同的平台架构分别有一个,不过一般紧接着会把这些聚合成一个通用的 library。)。同时注意,不同的 target 也是有编译顺序的,具体的要看 target 之间的依赖关系。

在 xcode 编译的过程中,大部分的命令都可以自解释,不过仍有个别的命令直接看是看不出来干嘛的,这里解释一下:
ld :用于产生可执行文件。
libtool:产生 lib 的工具。
(这部分将会在之后的文章的编译具体过程进行讲解)

接下来就是编译过程的控制,在 xcode 中可以通过 Build phases,Build settings以及 Build rules来进行控制。

Build phases主要是用来控制从源文件到可执行文件的整个过程的,所以应该说是面向源文件的,包括编译哪些文件,以及在编译过程中执行一些自定义的脚本什么的。
Build rules 主要是用来控制如何编译某种类型的源文件的,假如说相对某种类型的原文件进行特定的编译,那么就应该在这里进行编辑了。同时这里也会大量的运用一些 xcode 中的环境变量,完整的官方文档在这里:Build Settings Reference
Build settings则是对编译工作的细节进行设定,在这个窗口里可以看见大量的设置选项,从编译到打包再到代码签名都有,这里要注意 settings 的 section 分类,同时一般通过右侧的 inspector 就可以很好的理解选项的意义了。

最后,要说一下我们的工程文件.pbxproj,以上的所有的这些选项都保存在这个文件中。当然也包括 target 的信息,项目所有文件的信息,这个文件是一个文本文件,可以用文本编辑器打开。里头的内容基本是可读性比较强的。基本的思路很面向对象,每个东西都有属性,如果属性是另一个对象,值就是那个对象的一个『引用』,就是一串数字(唯一的)作为表示。每个对象都有这样的引用。

编译器

首先,编译器是做什么的?编译器是用来把源代码文件转换为更为低级的语言的(同时还有语句的静态分析),而 xcode 使用的clang 编译器的作用就是把源代码转换为更为低级的 LLVM IR(Intermedia Representation),这个 LLVM IR 是操作系统无关的,然后 LLVM 通过这个中间语言来进行下一步的二进制文件的产出。得益于 LLVM 的三层架构,LLVM 可以有多个输入和输出(LLVM 的第一层架构是用于处理输入的,第二层用于优化 IR ,第三层用于输出)这里遇到了一个问题,不了解到底 clang 和 LLVM 之间的关系是什么,估计得明白编译器是怎么做的才能明白。

通常一个编译器可以编译多种语言,生成多个平台的代码,所以会划分前端和后端。有时候还有中端的说法。

前端是语言相关的,输出为抽象语法树;
后端是机器相关的,输出为机器代码。有些优化是机器无关的,这一部分可能被单列出来称为中端。

以gcc为例,前端生成的中间语言为GENERIC,之后转化为gimple做机器无关的优化,最后转化为RTL做机器相关优化并生成机器代码。
这三个部分就可以分别称为前端、中端、后端。不过gimple阶段是gcc 4之后才有的,gcc 3.x的版本优化全在RTL上。
而且实际实现的时候可能机器相关的优化也在gimple阶段实现(反过来RTL也有机器无关优化),划分不是那么明确。

也就是说前段完成语法分析句法分析等相关的工作,并不会针对机器平台做想对应的优化。后端才是真正蟾蜍机器码的部分。clang 只是一个编译器的前前端部分。而 LLVM 这个术语不能一概而论,具体区别的在这篇博客有讲述。

如果对编译器本身产生了兴趣,可以一方面可以看看编译原理(程序猿的三大浪漫之一),然后另一方面可以自己了解一个编译器应该怎么写。
这里有个

申明:本文是为了本人更好的翻阅记忆,原文链接

其他相关文档:

1、从零开始写个编译器

2、同时还有斯坦福大学的公开课知乎专栏可以参考

3、用Xcode查看预处理文件方法