LLVM编译流程_插件开发
2024 - 02 - 02
Posted by 一荤一素一碗粥
本文学习引用iOS-底层原理 31:LLVM编译流程 & Clang插件开发,在此致谢
本文主要是理解LLVM的编译流程以及clang插件的开发
LLVM
LLVM是架构编译器的框架系统,以C++编写而成,用于优化任意程序语言编写的程序的编译时间(compile-time)、链接时间(link-time)、运行时间(run-time)以及空闲时间(idle-time)。对开发者保持开放,并兼容已有脚本。
传统编译器设计
源码 Source Code + 前端 Frontend + 优化器 Optimizer + 后端 Backend(代码生成器 CodeGenerator)+ 机器码 Machine Code,如下图所示
iOS的编译器架构
OC、C、C++使用的编译器前端是Clang,Swift是swift,后端都是LLVM,如下图所示
模块说明
- 前端 Frontend:编译器前端的
任务是解析源代码(编译阶段),它会进行词法分析、语法分析、语义分析、检查源代码是否存在错误,然后构建抽象语法树(Abstract Syntax TreeAST),LLVM的前端还会生成中间代码(intermediate representation,简称IR),可以理解为llvm是编译器 + 优化器, 接收的是IR中间代码,输出的还是IR,给后端Backend,经过后端翻译成目标指令集 - 优化器 Optimizer:优化器负责进行各种优化,改善代码的运行时间,例如消除冗余计算等
- 后端 Backend(代码生成器 Code Generator) :将
代码映射到目标指令集,生成机器代码,并且进行机器代码相关的代码优化
LLVM的设计
LLVM设计的最重要方面是,使用通用的代码表示形式(IR),它是用来在编译器中表示代码的形式,所有LLVM可以为任何编程语言独立编写前端,并且可以为任意硬件架构独立编写后端,如下所示
通俗的一句话理解就是:LLVM的设计是前后端分离的,无论前端还是后端发生变化,都不会影响另一个。
Clang简介
clang是LLVM项目中的一个子项目,它是基于LLVM架构图的轻量级编译器,诞生之初是为了替代GCC,提供更快的编译速度,它是负责C、C++、OC语言的编译器,属于整个LLVM架构中的 编译器前端,对于开发者来说,研究Clang可以给我们带来很多好处
LLVM编译流程
-
新建一个文件,写下如下代码
arduino
复制代码
int test(int a,int b){ return a + b + 3; } int main(int argc, const char * argv[]) { int a = test(1, 2); printf("%d",a); return 0; } -
通过命令可以打印源码的编译流程
arduino
复制代码
//************命令************ clang -ccc-print-phases main.m //************编译流程************ //0 - 输入文件:找到源文件 +- 0: input, "main.m", objective-c //1 - 预处理阶段:这个过程处理包括宏的替换,头文件的导入 +- 1: preprocessor, {0}, objective-c-cpp-output //2 - 编译阶段:进行词法分析、语法分析、检测语法是否正确,最终生成IR +- 2: compiler, {1}, ir //3 - 后端:这里LLVM会通过一个一个的pass去优化,每个pass做一些事情,最终生成汇编代码 +- 3: backend, {2}, assembler //4 - 汇编代码生成目标文件 +- 4: assembler, {3}, object //5 - 链接:链接需要的动态库和静态库,生成可执行文件 +- 5: linker, {4}, image(镜像文件) //6 - 绑定:通过不同的架构,生成对应的可执行文件 6: bind-arch, "x86_64", {5}, image
其中0主要是输入文件,即找到源文件。这里不做过多说明。下面对之后流程分别来解释。
一、预处理编译阶段
这个阶段主要是处理包括宏的替换,头文件的导入,可以执行如下命令,执行完毕可以看到头文件的导入和宏的替换
less
复制代码
//在终端直接查看替换结果 clang -E main.m //结果有点多 把结果输出到 main2.m查看 clang -E main.m >> main2.m
需要注意的是:
typedef在给数据类型取别名时,在预处理阶段不会被替换掉define则在预处理阶段会被替换,所以经常被是用来进行代码混淆。一般为了不被逆向会把应用核心类、敏感方法等用系统相似的名称进行取别名了,然后在预处理阶段就被替换了,来达到代码混淆的目的。
二、编译阶段
编译阶段主要是进行词法、语法等的分析和检查,然后生成中间代码IR
1、词法分析
预处理完成后就会进行词法分析,这里会把代码切成一个个token,比如大小括号、等于号还有字符串等,
-
可以通过下面的命令查看
css
复制代码
clang -fmodules -fsyntax-only -Xclang -dump-tokens main.m -
如果头文件找不到,指定sdk
bash
复制代码
clang -isysroot (自己SDK路径) -fmodules -fsyntax-only -Xclang -dump-tokens main.m clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.1.sdk/ -fmodules -fsyntax-only -Xclang -dump-tokens main.m
以下是代码的词法分析结果:
2、语法分析
词法分析完成后就是语法分析,它的任务是验证语法是否正确,在词法分析的基础上将单词序列组合成各类此法短语,如程序、语句、表达式 等等,然后将所有节点组成抽象语法树(Abstract Syntax TreeAST),语法分析程序判断程序在结构上是否正确
-
可以通过下面命令查看语法分析的结果
css
复制代码
clang -fmodules -fsyntax-only -Xclang -ast-dump main.m -
如果导入头文件找不到,可以指定SDK
bash
复制代码
clang -isysroot (自己SDK路径) -fmodules -fsyntax-only -Xclang -ast-dump main.m clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.1.sdk/ -fmodules -fsyntax-only -Xclang -ast-dump main.m
下面是语法分析的结果:
其中,主要说明几个关键字的含义
- -FunctionDecl 函数
- -ParmVarDecl 参数
- -CallExpr 调用一个函数
- -BinaryOperator 运算符
3、生成中间代码IR
完成以上步骤后,就开始生成中间代码IR了,代码生成器(Code Generation)会将语法树自顶向下遍历逐步翻译成LLVM IR,
- 可以通过下面命令可以生成
.ll的文本文件,查看IR代码。OC代码在这一步会进行runtime桥接,:property合成、ARC处理等
less
复制代码
clang -S -fobjc-arc -emit-llvm main.m //以下是IR基本语法 @ 全局标识 % 局部标识 alloca 开辟空间 align 内存对齐 i32 32bit,4个字节 store 写入内存 load 读取数据 call 调用函数 ret 返回
下面是生成的中间代码.ll文件
其中,test函数的参数解释为
-
当然,IR文件在OC中是可以进行优化的,一般设置是在
target - Build Setting - Optimization Level(优化器等级)中设置。LLVM的优化级别分别是-O0 -O1 -O2 -O3 -Os(第一个是大写英文字母O),下面是带优化的生成中间代码IR的命令css
复制代码
clang -Os -S -fobjc-arc -emit-llvm main.m -o main.ll这是优化后的中间代码:
-
xcode7以后开启
bitcode,苹果会做进一步优化,生成.bc的中间代码,我们通过优化后的IR代码生成.bc代码css
复制代码
clang -emit-llvm -c main.ll -o main.bc
三、后端
LLVM在后端主要是会通过一个个的Pass去优化,每个Pass做一些事情,最终生成汇编代码
生成汇编代码
-
我们通过最终的
.bc或者.ll代码生成汇编代码css
复制代码
clang -S -fobjc-arc main.bc -o main.s clang -S -fobjc-arc main.ll -o main.s -
生成汇编代码也可以进行优化
css
复制代码
clang -Os -S -fobjc-arc main.m -o main.s
此时查看生成的main.s文件的格式为汇编代码
四、生成目标文件
目标文件的生成,是汇编器以汇编代码作为插入,将汇编代码转换为机器代码,最后输出目标文件(object file)
css
复制代码
clang -fmodules -c main.s -o main.o
可以通过nm命令,查看下main.o中的符号
bash
复制代码
$xcrun nm -nm main.o
以下是main.o中的符号,其文件格式为 目标文件
_printf函数是一个是undefined 、external的undefined表示在当前文件暂时找不到符号_printfexternal表示这个符号是外部可以访问的
五、链接
链接主要是链接需要的动态库和静态库,生成可执行文件,其中
- 静态库会和可执行文件合并
- 动态库是独立的
连接器把编译生成的.o文件和 .dyld .a文件链接,生成一个mach-o文件
css
复制代码
clang main.o -o main
查看链接之后的符号:
css
复制代码
xcrun nm -nm main
结果如下所示,其中的undefined表示会在运行时进行动态绑定
通过命令查看 main是什么格式,此时是 mach-o可执行文件
六、绑定
绑定主要是通过不同的架构,生成对应的mach-o格式可执行文件
总结
综上,所述,LLVM的编译流程如下图所示:
Clang插件开发
1、准备工作
1.0 下载clang、clang-tools-extra、compiler-rt、libcxx、libcxxabi、llvm五个库:(我下载的都是13.0.0版本的)\
解压并移除名称中的版本号
-
按以下顺序将
文件夹移到指定位置:-
将
clang-tools-extra移到clang文件夹中的clang/tools文件中 -
将
clang文件夹移到llvm/tools中 -
将
compiler-rt、libcxx、libcxxabi都移到llvm/projects中
-
1.1 安装cmake
-
通过
brew list查看brew是否安装cmake,如果已经安装,则跳过下面步骤复制代码
brew list -
通过
brew安装cmake复制代码
brew install cmake
1.2 编译LLVM
有两种编译方式:
- 通过
xcode编译LLVM - 通过
ninja编译LLVM
本文只介绍通过xcode编译LLVM。
通过xcode编译LLVM
-
cmake将
llvm编译成Xcode项目bash
复制代码
mkdir build_xcode //在 llvm同等路径下 cd build_xcode cmake -G Xcode ../llvm // 或者: cmake -G Xcode CMAKE_BUILD_TYPE="Release" ../llvm // 或者: cmake -G Xcode CMAKE_BUILD_TYPE="debug" ../llvm
build文件夹是存放cmake生成的Xcode文件的。放哪里都可以。cmake编译的对象是llvm文件。所以使用cmake -G Xcode ../llvm编译并生成Xcode文件时,请核对llvm的文件路径。
这时候build_xcode会有一个xcode项目
- xcode打开此项目,会有以下弹窗
选择Manually Manage Schemes,会弹窗出
添加
clang和clangTooling两个Target,并完成两个target的编译(command+b). 编译成功后,我们的准备工作就完成了。可以正式开始插件开发了
2、自定义插件
-
在
/llvm/tools/clang/tools下新建插件MMPlugin -
在
/llvm/tools/clang/tools目录下的CMakeLists.txt文件,新增add_clang_subdirectory(MMPlugin),此处的MMPlugin即为上一步创建的插件名称
-
在
MMPlugin目录下新建两个文件,分别是MMPlugin.cpp和CMakeLists.txtbash
复制代码
//通过终端在MMPlugin目录下创建 touch MMPlugin.cpp touch CMakeLists.txt并在
CMakeLists.txt中加上以下代码:scss
复制代码
//CMakeLists.txt中添加以下代码 add_llvm_library( MMPlugin MODULE BUILDTREE_ONLY MMPlugin.cpp ) -
接下来利用cmake重新生成Xcode项目,在
build_xcode目录下执行以下命令bash
复制代码
cmake -G Xcode ../llvm -
就可以在LLVM的xCode项目中可以看到
Loadable modules目录下由自定义的MMPlugin目录了,然后可以在里面编写插件代码了
-
新增scheme
MMPlugin然后command+b编译一下,在
/build_xcode/Debug/lib会多了一个MMPlugin.dylib
编写插件代码
在MMPlugin目录下的MMPlugin.cpp文件中,加入以下代码:
js
复制代码
/* 校验NSString | NSArray | NSDictionary属性是否被copy修饰 */ #include <iostream> #include "clang/AST/AST.h" #include "clang/AST/DeclObjC.h" #include "clang/AST/ASTConsumer.h" #include "clang/ASTMatchers/ASTMatchers.h" #include "clang/Frontend/CompilerInstance.h" #include "clang/ASTMatchers/ASTMatchFinder.h" #include "clang/Frontend/FrontendPluginRegistry.h" using namespace clang; using namespace std; using namespace llvm; using namespace clang::ast_matchers; //命名空间,和插件同名 namespace MMPlugin { //第三步:扫描完毕的回调函数 //4、自定义回调类,继承自MatchCallback class MMMatchCallback: public MatchFinder::MatchCallback { private: //CI传递路径:MMASTAction类中的CreateASTConsumer方法参数 - MMConsumer的构造函数 - MMMatchCallback的私有属性,通过构造函数从MMASTConsumer构造函数中获取 CompilerInstance &CI; //判断是否是用户源文件 bool isUserSourceCode(const string filename) { //文件名不为空 if (filename.empty()) return false; //非xcode中的源码都认为是用户的 if (filename.find("/Applications/Xcode.app/") == 0) return false; return true; } //判断是否应该用copy修饰 bool isShouldUseCopy(const string typeStr) { //判断类型是否是NSString | NSArray | NSDictionary if (typeStr.find("NSString") != string::npos || typeStr.find("NSArray") != string::npos || typeStr.find("NSDictionary") != string::npos/*...*/) { return true; } return false; } public: MMMatchCallback(CompilerInstance &CI) :CI(CI) {} //重写run方法 void run(const MatchFinder::MatchResult &Result) { //通过result获取到相关节点 -- 根据节点标记获取(标记需要与MMASTConsumer构造方法中一致) const ObjCPropertyDecl *propertyDecl = Result.Nodes.getNodeAs<ObjCPropertyDecl>("objcPropertyDecl"); //判断节点有值,并且是用户文件 if (propertyDecl && isUserSourceCode(CI.getSourceManager().getFilename(propertyDecl->getSourceRange().getBegin()).str()) ) { //15、获取节点的描述信息 ObjCPropertyDecl::PropertyAttributeKind attrKind = propertyDecl->getPropertyAttributes(); //获取节点的类型,并转成字符串 string typeStr = propertyDecl->getType().getAsString(); // cout<<"---------拿到了:"<<typeStr<<"---------"<<endl; //判断应该使用copy,但是没有使用copy if (propertyDecl->getTypeSourceInfo() && isShouldUseCopy(typeStr) && !(attrKind & ObjCPropertyDecl::OBJC_PR_copy)) { //使用CI发警告信息 //通过CI获取诊断引擎 DiagnosticsEngine &diag = CI.getDiagnostics(); //通过诊断引擎 report报告 错误,即抛出异常 /* 错误位置:getBeginLoc 节点开始位置 错误:getCustomDiagID(等级,提示) */ diag.Report(propertyDecl->getBeginLoc(), diag.getCustomDiagID(DiagnosticsEngine::Warning, "%0 - 这个地方推荐使用copy!!"))<< typeStr; } } } }; //第二步:扫描配置完毕 //3、自定义MMASTConsumer,继承自ASTConsumer,用于监听AST节点的信息 -- 过滤器 class MMASTConsumer: public ASTConsumer { private: //AST节点的查找过滤器 MatchFinder matcher; //定义回调类对象 MMMatchCallback callback; public: //构造方法中创建matcherFinder对象 MMASTConsumer(CompilerInstance &CI) : callback(CI) { //添加一个MatchFinder,每个objcPropertyDecl节点绑定一个objcPropertyDecl标识(去匹配objcPropertyDecl节点) //回调callback,其实是在MMMatchCallback里面重写run方法(真正回调的是回调run方法) matcher.addMatcher(objcPropertyDecl().bind("objcPropertyDecl"), &callback); } //实现两个回调方法 HandleTopLevelDecl 和 HandleTranslationUnit //解析完一个顶级的声明,就回调一次(顶级节点,相当于一个全局变量、函数声明) bool HandleTopLevelDecl(DeclGroupRef D){ // cout<<"正在解析..."<<endl; return true; } //整个文件都解析完成的回调 void HandleTranslationUnit(ASTContext &context) { // cout<<"文件解析完毕!"<<endl; //将文件解析完毕后的上下文context(即AST语法树) 给 matcher matcher.matchAST(context); } }; //2、继承PluginASTAction,实现我们自定义的Action,即自定义AST语法树行为 class MMASTAction: public PluginASTAction { public: //重载ParseArgs 和 CreateASTConsumer方法 bool ParseArgs(const CompilerInstance &ci, const std::vector<std::string> &args) { return true; } //返回ASTConsumer类型对象,其中ASTConsumer是一个抽象类,即基类 /* 解析给定的插件命令行参数。 - param CI 编译器实例,用于报告诊断。 - return 如果解析成功,则为true;否则,插件将被销毁,并且不执行任何操作。该插件负责使用CompilerInstance的Diagnostic对象报告错误。 */ unique_ptr<ASTConsumer> CreateASTConsumer(CompilerInstance &CI, StringRef iFile) { //返回自定义的MMASTConsumer,即ASTConsumer的子类对象 /* CI用于: - 判断文件是否使用户的 - 抛出警告 */ return unique_ptr<MMASTConsumer> (new MMASTConsumer(CI)); } }; } //第一步:注册插件,并自定义AST语法树Action类 //1、注册插件 static FrontendPluginRegistry::Add<MMPlugin::MMASTAction> MM("MMPlugin", "This is MMPlugin");
其原理主要分为三步
-
【第一步】注册插件,并自定义AST语法树Action类
- 继承自
PluginASTAction,自定义ASTAction,需要重载两个方法ParseArgs和CreateASTConsumer,其中的重点方法是CreateASTConsumer,方法中有个参数CI即编译实例对象,主要用于以下两个方面- 用于判断文件是否是用户的
- 用于xCode抛出警告
- 通过
FrontendPluginRegistry注册插件,需要关联插件名与自定义的ASTAction类
- 继承自
-
【第二步】扫描配置完毕
- 继承自
ASTConsumer类,实现自定义的子类MMASTConsumer,有两个参数MatchFinder对象matcher以及MMMatchCallback自定义的回调对象callback - 实现构造函数,主要是创建
MatchFinder对象,以及将CI床底给回调对象 - 实现两个回调方法
HandleTopLevelDecl:解析完一个顶级的声明,就回调一次HandleTranslationUnit:整个文件都解析完成的回调,将文件解析完毕后的上下文context(即AST语法树) 给matcher
- 继承自
-
【第三步】扫描完毕的回调函数
- 继承自
MatchFinder::MatchCallback,自定义回调类MMMatchCallback - 定义
CompilerInstance私有属性,用于接收ASTConsumer类传递过来的CI信息 - 重写run方法
- 1、通过result,根据节点标记,获取相应节点,此时的标记需要与
MMASTConsumer构造方法中一致 - 2、判断节点有值,并且是用户文件即
isUserSourceCode私有方法 - 3、获取节点的描述信息
- 4、获取节点的类型,并转成字符串
- 5、判断应该使用copy,但是没有使用copy
- 6、通过
CI获取诊断引擎 - 7、通过诊断引擎报告错误
- 1、通过result,根据节点标记,获取相应节点,此时的标记需要与
- 继承自
所以,综上所述,clang插件开发的流程图如下: 测试工程代码:
然后在终端中测试插件:
bash
复制代码
//命令格式 自己编译的clang文件路径 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.1.sdk/ -Xclang -load -Xclang 插件(.dyld)路径 -Xclang -add-plugin -Xclang 插件名 -c 源码路径 //例子 /Users/XXX/Desktop/build_xcode/Debug/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator15.0.sdk/ -Xclang -load -Xclang /Users/XXXX/Desktop/build_xcode/Debug/lib/MMPlugin.dylib -Xclang -add-plugin -Xclang MMPlugin -c /Users/XXXX/Desktop/XXX/XXXX/测试demo/testClang/testClang/ViewController.m
3、Xcode集成插件
加载插件
-
打开测试项目,在
target->Build Settings -> Other C Flags添加以下内容csharp
复制代码
-Xclang -load -Xclang (.dylib)动态库路径 -Xclang -add-plugin -Xclang MMPlugin -
编译测试项目 就会出现下面效果
如果前文下载的clang和Xcode版本不一致,编译测试工程会导致下面失败,如下图所示:
需要在Xcode设置下编译器:
- 在
Build Settings栏目中新增两项用户定义的设置,分别是CC和CXX
CC对应的是自己编译的clang的绝对路径CXX对应的是自己编译的clang++的绝对路径![]()
- 在
Build Settings中搜索index,将Enable Index-Wihle-Building Functionality的Default改为NO然后重新编译测试项目就可以了。