1.[clang]: llvm 前端编译流程
2.LLVM IR 指南
3.一文带你梳理Clang编译步骤及命令
4.WebRTC入门：iOS工程

[clang]: llvm 前端编译流程

       clang编译流程分为五个主要步骤：预处理器、码分编译器、码分后端生成、码分汇编、码分链接器。码分

       预处理阶段主要进行文本替换操作，码分杀毒引擎源码处理编译语言中的码分预处理指令，如导入头文件和宏替换等，码分不进行语法和词法检测。码分

       编译器阶段通过词法分析和语法分析，码分将预处理结果转换成抽象语法树（AST），码分以便生成中间表示（IR）。码分例如，码分从文件test.cc生成的码分AST将会被转换成可读的文本中间表示（ll）或不可读的bitcode（bc）文件。

       生成IR阶段，码分AST被转换为中间表示格式，确保正确识别代码的语法结构。bitcode（bc）和ll文件为两种不同的中间表示形式，二者可以相互转换。通过指令可以实现从中间表示到汇编语言的转换。

       汇编阶段，使用指令将中间表示转换为汇编代码（test.s），汇编语言代码可用于运行或进一步转换。

       最后阶段是链接器，将生成的汇编代码（或其他类型的目标文件）链接为可执行文件或动态库。

       总结，var 12指标源码整个流程包含以下关键输出文件：

       - test.c：源代码输入

       - test.i：预处理输出文件

       - test.bc：bitcode中间表示文件

       - test.ll：可读的文本中间表示文件

       - test.s：汇编代码输出

       - test.o：单文件生成的二进制文件

       - image：最终的可执行文件

       注意流程图中箭头方向表示文件转换方向，实线部分介绍Clang编译器相关功能，虚线部分不涉及。

LLVM IR 指南

       LLVM IR是一种通用的程序表示形式，编程语言编译器通过前端生成并经过一系列分析和转换（称为pass）生成优化后的IR。这种表示允许跨语言和硬件的隔离，便于优化，并支持在不同阶段进行优化，比如runtime时，IR会被保留并在发现可优化点时进行重新编译。

       LLVM IR有三种形式：内存中的ir、硬盘上的bitcode文件(ir.bc)和供人阅读的文本形式(ir.ll)。在编译过程中，ir的内存格式用于全阶段优化，特别是在需要runtime优化时。

       LLVM工具链包含了编译LLVM源码所需的工具，通常在编译目录的bin目录下。要生成IR的基本结构，可以使用clang命令。IR的基本结构由module、function、basicblock和instruction组成，每个模块可能包含多个函数，每个函数由多个基本块构成，体现了控制流的cf手游苹果提取源码执行逻辑。

       LLVM的Pass Manager执行分析和转换，包括analysis pass和transform pass。新旧Pass Manager在结构和命令行使用上有所不同。Pass的执行顺序通常从module开始，逐步深入到function、loop等层次，涉及到如别名分析、MemorySSA和Loop-Invariant-code-motion等优化策略。

       例如，别名分析分析变量的load/store操作产生的别名，通过构建语句间的约束和迭代生成alias，提供函数间的内存依赖信息。MemorySSA则在此基础上，提供内存依赖查询，便于IR的分析和transform pass。

       Link-time优化是LLVM的另一大优势，它允许在链接阶段对整个程序的IR进行优化，利用内存中的IR进行更深入的分析和改进。这比传统编译过程中的优化更为灵活和高效。

       调试和命令行使用方面，LLVM提供了丰富的工具和技巧，帮助开发者在编译过程中进行调试和优化，比如MakeFile中的关键语句和调试技巧。

一文带你梳理Clang编译步骤及命令

       摘要： 本文简单介绍了Clang编译过程中涉及到的步骤和每个步骤的产物，并简单分析了部分影响预处理和编译成功的偷偷派发分析指标公式源码部分因素。

       本文简单介绍部分Clang和LLVM的编译命令。更关注前端部分（生成 IR 部分）。

1. Clang编译步骤概览

       我们可以使用命令打印出来Clang支持的步骤，如下：

clang-ccc-print-phasestest.c+-0:input,"test.c",c+-1:preprocessor,{ 0},cpp-output+-2:compiler,{ 1},ir+-3:backend,{ 2},assembler+-4:assembler,{ 3},object5:linker,{ 4},image

       根据上面的介绍，可以根据每一部分的结果，分为5个步骤（不包含上面的第0步）：preprocessor、compiler、backend、assembler、linker等。

       具体到 Clang 中每一步骤生成的结果文件。我们可以使用下面的示意图来表示：

       说明：上面的示意图以Clang编译一个C文件为例，介绍了Clang编译过程中涉及到的中间文件类型：

       (1) test.c 为输入的源码（对应步骤 0）；

       (2) test.i 为预处理文件（对应步骤 1 的输出，cpp-output 中，cpp 不是指 C++ 语言，而是 c preprocessor 的 缩写）；

       (3) test.bc 为 bitcode文件，是clang的一种中间表示（对应步骤 2 的输出）；

       (4) test.ll 为一种文本化的中间表示，可以打开来看的（对应步骤 2 的输出， 和 .bc 一样都是中间表示，可以相互转化）；

       (5) test.s 为汇编结果（对应步骤 3 的输出）；

       (6) test.o 为单文件生成的二进制文件（对应步骤 4 的输出）；

       (7) image 为可执行文件（对应步骤 5 的输出）。

       注意：示意图画的也并不完整，如下介绍：

       (1) 箭头所指的方向，表示可以从一种类型的文件，生成箭头所指的文件类型；

       (2) 图中箭头并没有画完，比如可以从 test.c 生成 test.s,macd专用选股器源码 test.o 等。如果将上面的示意图当做一种 有向图，那么基于 箭头 所指的方向，只要 节点能连接的点，都是可以做转换的；

       (3) 图中的实线和虚线，只是表示本人关心的Clang编译器中的内容，并没有其他的含义，本文也只介绍图中实线部分的内容，虚线部分的内容不做介绍。

2. 转换命令集合

       下面介绍部分涉及到上面步骤的转换命令：

#1..c->.iclang-E-ctest.c-otest.i#2..c->.bcclang-emit-llvmtest.c-c-otest.bc#3..c->.llclang-emit-llvmtest.c-S-otest.ll#4..i->.bcclang-emit-llvmtest.i-c-otest.bc#5..i->.llclang-emit-llvmtest.i-S-otest.ll#6..bc->.llllvm-distest.bc-otest.ll#7..ll->.bcllvm-astest.ll-otest.bc#8.多bc合并为一个bcllvm-linktest1.bctest2.bc-otest.bc

       上面列出了一部分Clang不同文件直接转换的命令（和第 1 部分的 示意图 序号匹配，还是只关心前端部分）。只是最后增加了一个将多个 bc 合并为一个 bc file 的命令。

3. 查看Clang AST结构

       我们可以通过如下的命令查看源码的AST结构：

clang-Xclang-ast-dump-ctest.c

       打印出来的AST信息，其实是预处理之后展开的源码信息，源码的AST内容在打印出来的内容的最下面。

       如下面的代码：

#include<stdio.h>intmain(){ printf("hello");return0;}

       打印出来的部分AST（仅根当前文件内容匹配部分）如下：

       头上的头文件引用等已经展开，没有了，但是下面的 main 函数定义，则如上面的 FunctionDecl 所示，并且给出了 代码中的位置。这里就不详细分析AST的结构了，写几个例子比对一下就很容易理解。

4. 编译正确性的影响因素

       当前，很多静态代码分析工具，都采用 Clang 和 LLVM 作为底座来开发静态代码分析工具。Clang自己也有 clang-tidy 工具可以用来做 C/C++ 语言的静态代码分析。为了能够用 Clang 和 LLVM 来成功分析 C/C++ 代码，需要考虑如何成功使用 Clang 和 LLVM 来编译 C/C++ 代码。可以考虑的是，成功生成 bc file，是静态代码分析的基础操作。

4.1 影响预处理结果的因素

       预处理过程，作用跟名字一样，都可以不当做编译的一个步骤，而是编译的一个预处理操作。我们说得再直白一点儿，其实就是做了一个文本替换的活儿，就是对 C/C++ 代码中的 预处理指令 进行处理。预处理指令很简单，比如 #include，#define 等，都是预处理指令（可以参考：/en-us/cpp/preprocessor/preprocessor-directives?view=msvc-，或者google下，很多介绍的）。

       如果程序中没有预处理指令，即使我们随便瞎写的代码，预处理也一般不会有问题，如下的代码（main.c）：

abcdef

       我们仍然可以正确得到 预处理结果：

#1"main.c"#1"<built-in>"1#1"<built-in>"3#"<built-in>"3#1"<commandline>"1#1"<built-in>"2#1"main.c"2abcdef

       为了成功执行预处理执行，很容易理解，就是可以对程序中的所有的 预处理指令 进行处理。比如：

       (1) #include，依赖了一个头文件，我们能不能成功找到这个头文件；

       (2) #define，定义了一个宏，在程序中定义宏的时候，我们能不能准确找到宏（找到，还必须准确）；

       (3) 其他指令。

4.2 影响IR生成因素

       这一步是针对上一步生成的预处理指令，进行解析的操作。这一步才是最关键的，归根结底，我们需要保证一点：使Clang编译器可以正确识别出来代码中内容表示的语法结构，并且接纳这种语法结构！

       举一些简单例子：

       (1) -std 用来指定支持的 C/C++ 标准的，如果我们没有指定，那么就会采用 Clang 默认的标准来编译，就可能导致语法不兼容；

       (2) -Werror=* 等参数，可能将某些能识别的语法，给搞成错误的使用；

       (3) 其他的部分，跟语法识别的参数；

       (4) 还有一部分的语法，可能 Clang 自始至终就没有进行适配，这种就要考虑修改源码了。

4.3 链接相关因素

       在真正编译中，如果链接有问题，那就会失败，但是在静态代码分析中，链接有失败（无法链接）或者错误（不相关的给链接在一起），可能多点儿分析误报或者漏报，一般不会导致分析失败。这类问题，影响的不是中间表示的生成，而是分析结果（影响跨文件的过程间分析，影响对built-in函数的建模等）。

       一般，链接命令的捕获，target信息配置等，会影响这部分的能力。当然，也跟你实现的工具有关（如果实现的工具，就没有跨文件的能力，这部分内容也没啥影响）。

       作者：maijun。

WebRTC入门：iOS工程

       刚进入项目组，接手WebRTC相关任务。项目需求基于最新WebRTC版本进行二次开发，但其工程使用gn和ninja编译，每次修改需编译成lib或framework，过程繁琐。本文记录WebRTC OC工程分离过程中的经验与教训。

       WebRTC，全称为Web Real-Time Communication，是实现实时语音与视频通话的技术，由谷歌于年通过收购Global IP Solutions公司获得。自年5月开源以来，得到广泛支持与应用，成为下一代视频通话的标准。

       要获取WebRTC iOS版本源码，首先需设置git代理。由于不可抗力，需自行配置。

       编译WebRTC库时，使用GN生成ninja工程文件。了解GN与ninja基本使用，可以借助官方教程，直接编译出WebRTC.framework。官方提供编译脚本，可方便编译静态库或Framework版本，并支持指定编译条件，如debug版本或是否开启bitcode。

       目标是将WebRTC.framework集成至Xcode工程，仅关注OC部分的二次开发，减少对C++代码的关注。分离工程需在现有基础上进行，尽量减少源码修改。

       生成libjingle_peerconnection_all库，需在/webrtc/BUILD.gn文件中添加新目标，并在build/ios/build_ios_libs.sh脚本中增加编译选项。此过程需按照官方教程进行。

       创建WebRTC_OC工程，在webrtc/sdk/objc目录下，参照rtc_sdk_common_objc和rtc_sdk_framework_objc配置，选择性添加所需Framework文件夹代码文件。

       分离工程过程中，需关注现有代码库依赖。完全分离需对头文件引用进行大量修改。分离工程旨在最小化修改，进行优化。

       总结接触WebRTC代码的经验，分离OC工程虽有助于专注二次开发，但需谨慎处理现有代码库依赖问题。若需完全分离，需对源码进行大量修改。了解更多细节请参阅原文链接。