iOS之LLVM编译流程和Clang插件开发集成

最新推荐文章于 2022-06-12 20:11:50 发布

置顶 ╰つ栺尖篴夢ゞ

最新推荐文章于 2022-06-12 20:11:50 发布

阅读量1.2w

点赞数 3

分类专栏： iOS高级进阶文章标签： LLVM 与 Clang 编译流程插件开发 Xcode集成 C++

本文链接：https://blog.csdn.net/Forever_wj/article/details/110142197

版权

iOS高级进阶专栏收录该内容

61 篇文章 87 订阅

订阅专栏

LLVM 简介

一、什么是 LLVM？

LLVM 是构架编译器(compiler)的框架系统，以 C++ 编写而成，用于优化以任意程序语言编写的程序的编译时间(compile-time)、链接时间(link-time)、运行时间(runtime)以及空闲时间(idle-time)，对开发者保持开放，并兼容已有脚本。
LLVM 最早的时候是 Illinois 的一个研究项目，主要负责人是 Chris Lattner，他现在就职于Apple。Apple 目前也是 LLVM 项目的主要赞助者之一。
在理解 LLVM 时，我们可以认为它包括了一个狭义的 LLVM 和一个广义的 LLVM。广义的 LLVM 其实就是指整个 LLVM 编译器架构，包括了前端、后端、优化器、众多的库函数以及很多的模块；而狭义的 LLVM 其实就是聚焦于编译器后端功能（代码生成、代码优化、JIT等）的一系列模块和库。

二、传统编译器设计

传统编译器分三个阶段：前端（Frontend）-> 优化器（Optimizer）-> 后端（Backend）；
- 前端Frontend：负责分析源代码，可以检查语法级错误（包括词法分析、语法分析、语义分析），并构建针对语言的抽象语法树（AST：Abstract Syntax Tree）；抽象语法树可以进一步转换为优化，最终转为新的表示方式，然后再交给让优化器和后端处理，LLVM 的前端还会生成中间代码（intermediate representation，简称IR）；最终由后端生成可执行的机器码（可以理解为 LLVM 是编译器 + 优化器，接收的是 IR 中间代码，输出的还是 IR，给后端，经过后端翻译成目标指令集）；
- 优化器 Optimizer：优化器负责进行各种优化，改善代码的运行时间，例如消除冗余计算等；
- 后端 Backend（代码生成器 Code Generator）：将代码映射到目标指令集，生成机器代码，并且进行机器代码相关的代码优化；
源码 Source Code + 前端 Frontend + 优化器 Optimizer + 后端 Backend（代码生成器 CodeGenerator）+ 机器码 Machine Code，如下所示：

在这里插入图片描述

LLVM 的优点在于，中间表示IR代码编写良好，而且不同的前端语言最终都转换成同一种的IR。

三、iOS 的编译器架构

OC、C、C++ 使用的编译器前端是Clang，Swift是swift，后端都是LLVM，如下图所示：

在这里插入图片描述

四、LLVM 的设计

LLVM 设计的最重要方面是，使用通用的代码表示形式（IR），它是用来在编译器中表示代码的形式，所有 LLVM 可以为任何编程语言独立编写前端，并且可以为任意硬件架构独立编写后端，如下所示：

在这里插入图片描述

LLVM的优点：
- 中间表示IR代码编写良好，而且不同的前端语言最终都转换成统一的中间代码LLVM IR（LLVM Intermediate Representation）；
- 如果需要支持一种新的变成语言，那么只需要实现一个新的前端；
- 如果需要支持一种新的硬件设备，那么只需要实现一个新的后端；
- 优化阶段是一个通用的阶段，它只针对统一的LLVM IR，不论是支持新的编程语言，还是支持新的硬件设备，都不需要对优化阶段做修改；
- LLVM现在被座位实现何种静态和运行时编译语言的通用基础结构（GCC家族、Java、.NET、Python、Ruby、Scheme、Haskell、D等）；
- 相比之下，GCC的前端和后台没分的太开，前端后端耦合在一起，所以GCC为了支持一门新的语言，或者为了支持一个新的目标平台，就变的特别困难；

五、Clang

clang 是 LLVM 项目中的一个子项目，它是基于 LLVM 架构图的轻量级编译器，诞生之初是为了替代 GCC，提供更快的编译速度，它是负责 C、C++、OC 语言的编译器，属于整个 LLVM 架构中的编译器前端，对于开发者来说，研究 Clang 可以给我们带来很多好处。
相比于 GCC，Clang 具有如下优点：
- 编译速度块：在某平台上，Clang 的编译速度显著的快过 GCC（Debug 模式下编译 OC 速度比 GCC 快 3 倍）；
- 占用内存小：Clang 生成的AST所占用的内存是 GCC 的五分之一左右；
- 模块化设计：Clang 采用基于库的模块化设计，易于 IDE 集成及其他用途的重用；
- 诊断信息可读性强：在编译过程中，Clang 创建并保留了大量纤细的元数据；（metadata），有利于调试和错误信息更加友善；
- 设计清晰简单，易于理解，扩展性强。

六、Clang 与 LLVM

在这里插入图片描述

LLVM编译流程

一、通过命令打印源码编译阶段

clang -ccc-print-phases main.m
- 输入文件：找到源文件
  ± 0: input, “main.m”, objective-c
- 预处理阶段：这个过程处理包括宏的替换，头文件的导入
  ± 1: preprocessor, {0}, objective-c-cpp-output
- 编译阶段：进行词法分析、语法分析、检测语法是否正确，最终生成IR
  ± 2: compiler, {1}, ir
- 后端：这里LLVM会通过一个一个的pass去优化，每个pass做一些事情，最终生成汇编代码
  ± 3: backend, {2}, assembler
- 汇编代码生成目标文件
  ± 4: assembler, {3}, object
- 链接：链接需要的动态库和静态库，生成可执行文件
  ± 5: linker, {4}, image（镜像文件）
- 绑定：通过不同的架构，生成对应的可执行文件
  6: bind-arch, “x86_64”, {5}, image
新建一个工程，cd 到 main.m 路径，然后执行 clang -ccc-print-phases main.m，结果如下：

	yangdw@Kody LLVM %  clang -ccc-print-phases main.m      
	               +- 0: input, "main.m", objective-c
	            +- 1: preprocessor, {0}, objective-c-cpp-output
	         +- 2: compiler, {1}, ir
	      +- 3: backend, {2}, assembler
	   +- 4: assembler, {3}, object
	+- 5: linker, {4}, image
	6: bind-arch, "x86_64", {5}, image

二、预处理编译阶段

在 main.m 中键入以下代码：

	int test(int a,int b){
	    return a + b + 3;
	}
	
	int main(int argc, const char * argv[]) {
	    @autoreleasepool {
	        int a = test(1, 2);
	        printf("%d",a);
	    }
	    return 0;
	}

然后执行 clang -E main.m，可以看到，结果如下：

	# 9 "main.m" 2
	
	int test(int a,int b){
	    return a + b + 3;
	}
	
	int main(int argc, const char * argv[]) {
	    @autoreleasepool {
	        int a = test(1, 2);
	        printf("%d",a);
	    }
	    return 0;
	}

不难看出，这个阶段主要是处理了包括宏的替换和头文件的导入；

三、编译阶段

① 词法分析

预处理完成后就会进行词法分析，这里会把代码切成一个个Token，比如大小括号、等于号还有字符串等。
通过如下命令查看词法分析的结果：

	clang -fmodules -fsyntax-only -Xclang -dump-tokens main.m

执行结果如下：

	yangdw@Kody LLVM % clang -fmodules -fsyntax-only -Xclang -dump-tokens main.m
	annot_module_include '#import <Foundation/Foundation.h>
	
	int test(int a,int b){
	    return a + b + 3;
	}
	
	int main(int argc, con'		Loc=<main.m:8:1>
	int 'int'	 [StartOfLine]	Loc=<main.m:10:1>
	identifier 'test'	 [LeadingSpace]	Loc=<main.m:10:5>
	l_paren '('		Loc=<main.m:10:9>
	int 'int'		Loc=<main.m:10:10>
	identifier 'a'	 [LeadingSpace]	Loc=<main.m:10:14>
	comma ','		Loc=<main.m:10:15>
	int 'int'		Loc=<main.m:10:16>
	identifier 'b'	 [LeadingSpace]	Loc=<main.m:10:20>
	r_paren ')'		Loc=<main.m:10:21>
	l_brace '{'		Loc=<main.m:10:22>
	return 'return'	 [StartOfLine] [LeadingSpace]	Loc=<main.m:11:5>
	identifier 'a'	 [LeadingSpace]	Loc=<main.m:11:12>
	plus '+'	 [LeadingSpace]	Loc=<main.m:11:14>
	identifier 'b'	 [LeadingSpace]	Loc=<main.m:11:16>
	plus '+'	 [LeadingSpace]	Loc=<main.m:11:18>
	numeric_constant '3'	 [LeadingSpace]	Loc=<main.m:11:20>

如果头文件找不到，指定sdk：

	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

② 语法分析

词法分析完成后就是语法分析，它的任务是验证语法是否正确，在词法分析的基础上将单词序列组合成各类此法短语，如程序、语句、表达式等，然后将所有节点组成抽象语法树（Abstract Syntax Tree􏰊AST），语法分析程序判断程序在结构上是否正确。
可以通过下面命令查看语法分析的结果：

	clang -fmodules -fsyntax-only -Xclang -ast-dump main.m

如果导入头文件找不到，可以指定SDK：

	 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

语法分析的结果如下所示：

在这里插入图片描述

③ 生成中间代码IR

生成中间代码IR，代码生成器（Code Generation）会将语法树自顶向下遍历逐步翻译成LLVM IR；
可以通过下面命令可以生成.ll的文本文件，查看IR代码。

	clang -S -fobjc-arc -emit-llvm main.m

OC 代码在这一步会进行 runtime 桥接：property合成、ARC处理等；
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的命令：

	clang -Os -S -fobjc-arc -emit-llvm main.m -o main.ll

优化之后如下所示：

在这里插入图片描述

Xcode7 以后开启 bitcode，苹果会做进一步优化，生成.bc的中间代码，通过优化后的IR代码生成 .bc 代码：

	clang -emit-llvm -c main.ll -o main.bc

四、生成汇编代码（后端）

通过最终的.bc或者.ll代码生成汇编代码：

	 clang -S -fobjc-arc main.bc -o main.s 
	 clang -S -fobjc-arc main.ll -o main.s

生成汇编代码也可以进行优化：

	clang -Os -S -fobjc-arc main.m -o main.s

此时生成的main.s文件的格式为汇编代码：

	yangdw@Kody LLVM % clang -emit-llvm -c main.ll -o main.bc
	yangdw@Kody LLVM % clang -S -fobjc-arc main.bc -o main.s 
	yangdw@Kody LLVM % clang -Os -S -fobjc-arc main.m -o main.s
	yangdw@Kody LLVM % file main.s
	main.s: assembler source text, ASCII text

五、生成目标文件(编译器)

目标文件的生成，是汇编器以汇编代码作为插入，将汇编代码转换为机器代码，最后输出目标文件（object file）

	clang -fmodules -c main.s -o main.o

可以通过 nm 命令，查看下 main.o 中的符号：

	$xcrun nm -nm main.o

以下是 main.o 中的符号，其文件格式为目标文件：

	yangdw@Kody LLVM % clang -fmodules -c main.s -o main.o
	yangdw@Kody LLVM % $xcrun nm -nm main.o
	                 (undefined) external _objc_autoreleasePoolPop
	                 (undefined) external _objc_autoreleasePoolPush
	                 (undefined) external _printf
	0000000000000000 (__TEXT,__text) external _test
	000000000000000a (__TEXT,__text) external _main
	yangdw@Kody LLVM % file main.o                        
	main.o: Mach-O 64-bit object x86_64

分析说明：
- _printf 函数是一个是undefined 、external 的
- undefined 表示在当前文件暂时找不到符号_printf
- external 表示这个符号是外部可以访问的

六、链接

链接主要是链接需要的动态库和静态库，生成可执行文件，其中
- 静态库会和可执行文件合并；
- 动态库是独立的；
连接器把编译生成的 .o 文件和 .dyld .a 文件链接，生成一个mach-o文件：

	clang main.o -o main

查看链接之后的符号：

	$xcrun nm -nm main

其中的undefined表示会在运行时进行动态绑定：

	clang main.o -o main
	$xcrun	nm	-nm	main
	(undefined)	external	_printf（from	libSystem）															
	(undefined)	external	dyld_stub_binder（from libSystem）
	0000000100000000 (__TEXT,__text)[referenced	dynamically]	external	__execute_header
	0000000100003f20 (__TEXT,__text) external _test
	0000000100003f40 (__TEXT,__text) external _main
	0000000100008008 (__DATA,__data) non_external _dyld_private

查看 main 是什么格式，此时是 mach-o可执行文件：

	yangdw@Kody LLVM % file main
	main:Mach-O 64-bit executable x86_64

七、绑定

绑定主要是通过不同的架构，生成对应的mach-o格式可执行文件

八、LLVM 的编译流程如下

在这里插入图片描述

Clang插件开发

一、LLVM 下载

由于国内网络限制，需要借助镜像下载 LLVM 的源码：LLVM 的镜像链接
下载 LLVM 项目：

	git clone https://github.com/llvm/llvm-project.git
	或者
	git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/llvm.git

在 LLVM 的 tools 目录下下载 Clang：

	cd	llvm/tools
	git	clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/clang.git

在 LLVM 的 projects 目录下下载 compiler-rt、libcxx、libcxxabi：

	cd	../projects
	git	clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/compiler-rt.g
	it
	git	clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/libcxx.git
	git	clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/libcxxabi.git

在 Clang 的 tools 下安装 extra 工具：

	cd ../tools/clang/tools
	git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/clang-tools-extra.git

二、LLVM 编译

由于最新的 LLVM 只支持 cmake 来编译，所以需要安装 cmake。

① 安装 cmake

查看brew是否安装cmake，如果已经安装，则跳过下面步骤：

	brew list

通过 brew 安装 cmake：

	brew install cmake

② 通过 Xcode 编译 LLVM

cmake 编译成 Xcode 项目：

	// 在llvm同级目录下新建一个build_xcode文件
	mkdir	build_xcode
	cd	build_xcode
	// 编译llvm
	cmake	-G	Xcode	../llvm

如果编译过程中遇到如下的错误：删除构建目录下的 CMakeCache.txt 即可。

	CMake Error: Error: generator : Xcode
	Does not match the generator used previously: Ninja
	Either remove the CMakeCache.txt file and CMakeFiles directory or choose a different binary directory.

使用 Xcode 编译 Clang，选择自动创建 Schemes：

在这里插入图片描述

编译（CMD + B），选择 ALL_BUILD Secheme 进行编译（时间较长，预计一个小时以上）

在这里插入图片描述

如果编译过程中遇到错误：error: The i386 architecture is deprecated. You should update your ARCHS build setting to remove the i386 architecture。
只需要将对应中的 Build Settings 选项 Architectures 中的值切换为 Standard Architectures(64-bit Intel) 即可。
或者：选择手动创建Schemes，然后编译编译 Clang + ClangTooling 即可。

③ 通过 ninja 编译 LLVM

使用 ninja 进行编译则还需要安装 ninja，使用以下命令安装ninja：

	brew install ninja

在 LLVM 源码根目录下新建 build_ninja 目录，最终会在 build_ninja 目录下生成build.ninja；
在 LLVM 源码根目录下新建 llvm_release 目录，最终编译文件会在 llvm_release 文件夹路径下：

	cd llvm_build
	// -DCMAKE_INSTALL_PREFIX 指定 LLVM 的安装路径，注意：DCMAKE_INSTALL_PREFIX后面不能有空格
	cmake -G Ninja ../llvm -DCMAKE_INSTALL_PREFIX= 安装路径（本机为/ Users/xxx/xxx/LLVM/llvm_release）

一次执行编译，安装指令：

	ninja
	ninja install

三、创建插件

在 /llvm/tools/clang/tools 目录下新建插件 YDWPlugin：

在这里插入图片描述

在 /llvm/tools/clang/tools 目录下的 CMakeLists.txt 文件，新增add_clang_subdirectory(YDWPlugin)，此处的 YDWPlugin 即为上一步创建的插件名称；

在这里插入图片描述

在 YDWPlugin 目录下新建两个文件，分别是 YDWPlugi.cpp 和 CMakeLists.txt，并在CMakeLists.txt 中加上以下代码：

	// 通过终端在YDWPlugin目录下创建
	touch YDWPlugin.cpp
	touch CMakeLists.txt
	// CMakeLists.txt中添加以下代码
	add_llvm_library(YDWPlugin MODULE BUILDTREE_ONLY 
    YDWPlugin.cpp
)

利用 cmake 重新生成 Xcode 项目，在 build_xcode 目录下执行以下命令：

	cmake -G Xcode ../llvm

最后可以在 LLVM 的 Xcode 项目中可以看到 Loadable modules 目录下由自定义的YDWPlugin 目录，然后就可以在里面编写相应的插件代码。

在这里插入图片描述

四、编写插件代码

在 YDWPlugin 目录下的 YDWPlugin.cpp 文件中，加入以下代码：

// create by YDW
// 2020/11/25

#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 YDWPlugin {

//第三步：扫描完毕的回调函数
//4、自定义回调类，继承自MatchCallback
class YDWMatchCallback: public MatchFinder::MatchCallback {
    
private:
    //CI传递路径：YDWASTAction类中的CreateASTConsumer方法参数 - YDWConsumer的构造函数 - YDWMatchCallback的私有属性，通过构造函数从YDWASTConsumer构造函数中获取
    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:
    YDWMatchCallback(CompilerInstance &CI) :CI(CI) {}
    
    //重写run方法
    void run(const MatchFinder::MatchResult &Result) {
        //通过result获取到相关节点 -- 根据节点标记获取（标记需要与YDWASTConsumer构造方法中一致）
        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、自定义YDWASTConsumer，继承自ASTConsumer，用于监听AST节点的信息 -- 过滤器
class YDWASTConsumer: public ASTConsumer {
private:
    //AST节点的查找过滤器
    MatchFinder matcher;
    //定义回调类对象
    YDWMatchCallback callback;
    
public:
    //构造方法中创建matcherFinder对象
    YDWASTConsumer(CompilerInstance &CI) : callback(CI) {
        //添加一个MatchFinder，每个objcPropertyDecl节点绑定一个objcPropertyDecl标识（去匹配objcPropertyDecl节点）
        //回调callback，其实是在YDWMatchCallback里面重写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 YDWASTAction: 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) {
        //返回自定义的YDWASTConsumer,即ASTConsumer的子类对象
        /*
         CI用于：
         - 判断文件是否使用户的
         - 抛出警告
         */
        return unique_ptr<YDWASTConsumer> (new YDWASTConsumer(CI));
    }
    
};

}

// 第一步：注册插件，并自定义AST语法树Action类
// 1、注册插件
static FrontendPluginRegistry::Add<YDWPlugin::YDWASTAction> YDW("YDWPlugin", "This is YDWPlugin");

原理分析：
- ① 注册插件，并自定义AST语法树Action类
  - 继承自 PluginASTAction，自定义 ASTAction，需要重载两个方法 ParseArgs 和 CreateASTConsumer，其中的重点方法是 CreateASTConsumer，方法中有个参数 CI 即编译实例对象，主要用于判断文件是否是属于用户和抛出警告；
  - 通过 FrontendPluginRegistry 注册插件，需要关联插件名与自定义的 ASTAction 类；
- ② 扫描配置完毕
  - 继承自 ASTConsumer 类，实现自定义的子类 YDWASTConsumer，有两个参数 MatchFinder 对象 matcher 以及 YDWMatchCallback 自定义的回调对象 callback；
  - 实现构造函数，主要是创建 MatchFinder 对象，以及将 CI 传递给回调对象；
  - 实现两个回调方法：HandleTopLevelDecl：解析完一个顶级的声明，就回调一次；
    HandleTranslationUnit：整个文件都解析完成的回调，将文件解析完毕后的上下文context（即AST语法树）给 matcher；
- ③ 扫描完毕的回调函数
  - 继承自 MatchFinder::MatchCallback，自定义回调类 YDWMatchCallback；
  - 定义 CompilerInstance 私有属性，用于接收 ASTConsumer 类传递过来的 CI 信息；
  - 重写 run 方法：
    - 通过 result，根据节点标记，获取相应节点，此时的标记需要与 YDWASTConsumer 构造方法中一致；
    - 判断节点有值，并且是用户文件即 isUserSourceCode 私有方法；
    - 获取节点的描述信息；
    - 获取节点的类型，并转成字符串；
    - 判断应该使用 copy，但是没有使用 copy；
    - 通过 CI 获取诊断引擎；
    - 通过诊断引擎报告错误；

五、测试插件

在终端中测试插件：

	// 命令格式
	自己编译的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/iPhoneSimulator14.1.sdk/ -Xclang -load -Xclang /Users/XXXX/Desktop/build_xcode/Debug/lib/YDWPlugin.dylib -Xclang -add-plugin -Xclang YDWPlugin -c /Users/XXXX/Desktop/XXX/XXXX/测试demo/testClang/testClang/ViewController.m

结果展示：

	/Users/XXX/Desktop/build_xcode/Debug/bin/clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator14.1.sdk/ -Xclang -load -Xclang /Users/XXXX/Desktop/build_xcode/Debug/lib/YDWPlugin.dylib -Xclang -add-plugin -Xclang YDWPlugin -c /Users/XXXX/Desktop/XXX/XXXX/测试demo/testClang/testClang/ViewController.m
	...
	Controller.m:12: Warning:
		------- NSString* 没用 copy 修饰 --------
	@property (nonatomic, strong) NSString *name;
		------- NSArray* 没用 copy 修饰 --------
	@property (nonatomic, strong) NSArray *list;
	...

六、Xcode 集成插件

加载插件，打开测试项目，在 target -> Build Settings -> Other C Flags 添加以下内容：

	 -Xclang -load -Xclang (.dylib)动态库路径 -Xclang -add-plugin -Xclang YDWPlugin

在这里插入图片描述

设置编译器，由于 Clang 插件需要使用对应的版本去加载，如果版本不一致会导致编译失败，如下所示：

在这里插入图片描述

在 Build Settings 栏目中新增两项用户定义的设置，分别是 CC 和 CXX；
- CC 对应的是自己编译的 Clang 的绝对路径；
- CXX 对应的是自己编译的 Clang++ 的绝对路径；

在这里插入图片描述

接下来在 Build Settings 中搜索 index，将 Enable Index-Wihle-Building Functionality 的 Default 改为 NO；

在这里插入图片描述

最后，重新编译测试项目，会出现下面的效果：

在这里插入图片描述

╰つ栺尖篴夢ゞ

关注

3
点赞
踩
8

收藏

觉得还不错? 一键收藏
打赏
10
评论
iOS之LLVM编译流程和Clang插件开发集成

LLVM简介一、什么是LLVM？LLVM 是构架编译器(compiler)的框架系统，以C++编写而成，用于优化以任意程序语言编写的程序的编译时间(compile-time)、链接时间(link-time)、运行时间(run-time)以及空闲时间(idle-time)，对开发者保持开放，并兼容已有脚本。LLVM 最早的时候是 Illinois 的一个研究项目，主要负责人是Chris Lattner，他现在就职于Apple。Apple 目前也是 llvm 项目的主要赞助者之一。在理解 LLVM 时
复制链接

扫一扫