iOS llvm-2

本文主要是理解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 Tree AST），LLVM的前端还会生成中间代码（intermediate representation，简称IR），可以理解为llvm是编译器 + 优化器，接收的是IR中间代码，输出的还是IR，给后端，经过后端翻译成目标指令集
优化器 Optimizer：优化器负责进行各种优化，改善代码的运行时间，例如消除冗余计算等
后端 Backend（代码生成器 Code Generator）：将代码映射到目标指令集，生成机器代码，并且进行机器代码相关的代码优化

LLVM的设计

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

LLVM的设计

通俗的一句话理解就是：LLVM的设计是前后端分离的，无论前端还是后端发生变化，都不会影响另一个

Clang简介

clang是LLVM项目中的一个子项目，它是基于LLVM架构图的轻量级编译器，诞生之初是为了替代GCC，提供更快的编译速度，它是负责C、C++、OC语言的编译器，属于整个LLVM架构中的编译器前端，对于开发者来说，研究Clang可以给我们带来很多好处

LLVM编译流程

新建一个文件，写下如下代码

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;
}

通过命令可以打印源码的编译流程

//************命令************
 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主要是输入文件，即找到源文件。这里不做过多说明

一、预处理编译阶段

这个阶段主要是处理包括宏的替换，头文件的导入，可以执行如下命令，执行完毕可以看到头文件的导入和宏的替换

//在终端直接查看替换结果
clang -E main.m

//生成对应的文件查看替换后的源码
clang -E main.m >> main2.m

需要注意的是：

typedef 在给数据类型取别名时，在预处理阶段不会被替换掉
define则在预处理阶段会被替换，所以经常被是用来进行代码混淆，目的是为了app安全，实现逻辑是：将app中核心类、核心方法等用系统相似的名称进行取别名了，然后在预处理阶段就被替换了，来达到代码混淆的目的

二、编译阶段

编译阶段主要是进行词法、语法等的分析和检查，然后生成中间代码IR

1、词法分析

预处理完成后就会进行词法分析，这里会把代码切成一个个token，比如大小括号、等于号还有字符串等

可以通过下面的命令查看

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

如果头文件找不到，指定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

以下是代码的词法分析结果

2、语法分析

词法分析完成后就是语法分析，它的任务是验证语法是否正确，在词法分析的基础上将单词序列组合成各类此法短语，如程序、语句、表达式等等，然后将所有节点组成抽象语法树（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

下面是语法分析的结果

其中，主要说明几个关键字的含义
-F unctionDecl 函数

ParmVarDecl 参数
CallExpr 调用一个函数
BinaryOperator 运算符

3、生成中间代码IR

完成以上步骤后，就开始生成中间代码IR了，代码生成器（Code Generation）会将语法树自顶向下遍历逐步翻译成LLVM IR，

可以通过下面命令可以生成.ll的文本文件，查看IR代码。OC代码在这一步会进行runtime桥接，：property合成、ARC处理等

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

//以下是IR基本语法
@ 全局标识
% 局部标识
alloca 开辟空间
align 内存对齐
i32 32bit，4个字节
store 写入内存
load 读取数据
call 调用函数
ret 返回

下面是生成的中间代码.ll文件

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

三、后端

LLVM在后端主要是会通过一个个的Pass去优化，每个Pass做一些事情，最终生成汇编代码

生成汇编代码

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

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

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

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

四、生成目标文件

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

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

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

$xcrun nm -nm main.o

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

五、链接

链接主要是链接需要的动态库和静态库，生成可执行文件，其中

静态库会和可执行文件合并
动态库是独立的

连接器把编译生成的.o文件和 .dyld .a文件链接，生成一个mach-o文件

clang main.o -o main

查看链接之后的符号

xcrun nm -nm main

结果如下所示，其中的undefined表示会在运行时进行动态绑定

通过命令查看 main是什么格式，此时是 mach-o可执行文件

file main 
// 打印结果：main:Mach-O 64-bit executable x86_64

./main
// 打印结果 ：6%

六、绑定

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

总结

综上，所述，LLVM的编译流程如下图所示

Clang插件开发

1、准备工作

由于国内网络限制，需要借助镜像下载llvm的源码，此处为镜像链接

下载LLVM项目

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

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

cd ../projects

git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/compiler-rt.git

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

2、LLVM编译

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

安装cmake

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

brew list

通过brew安装cmake

brew install cmake

编译LLVM

有两种编译方式：

通过xcode编译LLVM
通过ninja编译LLVM

通过xcode编译LLVM(方式一)

cmake编译成Xcode项目

mkdir build_xcode

cd build_xcode

cmake -G Xcode ../llvm

使用xcode编译Clang

选择自动创建Schemes

编译（CMD + B），选择ALL_BUILD Secheme进行编译，预计1+小时

注：这里通过ALL_BUILD Secheme编译会报以下错误The i386 architecture is deprecated. You should update your ARCHS build setting to remove the i386 architecture，尝试着去解决，但是目前尚未找到好的解决方案（后续会补充）

替代方案：选择手动创建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后面不能有空格
cmake -G Ninja ../llvm -DCMAKE_INSTALL_PREFIX= 安装路径（本机为/ Users/xxx/xxx/LLVM/llvm_release）

一次执行编译，安装指令

ninja

ninja install

3、创建插件

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

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


//1、通过终端在HKPlugin目录下的创建
touch HKPlugin.cpp

touch CMakeLists.txt

//2、CMakeLists.txt中添加以下代码
add_llvm_library( HKPlugin MODULE BUILDTREE_ONLY 
    HKPlugin.cpp
)

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

cmake -G Xcode ../llvm

最后可以在LLVM的xcode项目中可以看到Loadable modules目录下由自定义的HKPlugin目录了，然后可以在里面编写插件代码了

编写插件代码

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


#include 
#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 HKPlugin {

//第三步：扫描完毕的回调函数
//4、自定义回调类，继承自MatchCallback
class HKMatchCallback: public MatchFinder::MatchCallback {
    
private:
    //CI传递路径：HKASTAction类中的CreateASTConsumer方法参数 - HKConsumer的构造函数 - HKMatchCallback的私有属性，通过构造函数从CJLASTConsumer构造函数中获取

    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:
    HKMatchCallback(CompilerInstance &CI) :CI(CI) {}
    
    //重写run方法
    void run(const MatchFinder::MatchResult &Result) {
        //通过result获取到相关节点 -- 根据节点标记获取（标记需要与CJLASTConsumer构造方法中一致）
        const ObjCPropertyDecl *propertyDecl = Result.Nodes.getNodeAs("objcPropertyDecl");
        //判断节点有值，并且是用户文件
        if (propertyDecl && isUserSourceCode(CI.getSourceManager().getFilename(propertyDecl->getSourceRange().getBegin()).str()) ) {
            //15、获取节点的描述信息
            ObjCPropertyDecl::PropertyAttributeKind attrKind = propertyDecl->getPropertyAttributes();
            //获取节点的类型，并转成字符串
            string typeStr = propertyDecl->getType().getAsString();
//            cout<<"---------拿到了："<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、自定义HKASTConsumer，继承自ASTConsumer，用于监听AST节点的信息 -- 过滤器
class HKASTConsumer: public ASTConsumer {
private:
    //AST节点的查找过滤器
    MatchFinder matcher;
    //定义回调类对象
    HKMatchCallback callback;
    
public:
    //构造方法中创建matcherFinder对象
    HKASTConsumer(CompilerInstance &CI) : callback(CI) {
        //添加一个MatchFinder，每个objcPropertyDecl节点绑定一个objcPropertyDecl标识（去匹配objcPropertyDecl节点）
        //回调callback，其实是在HKMatchCallback里面重写run方法（真正回调的是回调run方法）
        matcher.addMatcher(objcPropertyDecl().bind("objcPropertyDecl"), &callback);
    }
    
    //实现两个回调方法 HandleTopLevelDecl 和 HandleTranslationUnit
    //解析完一个顶级的声明，就回调一次(顶级节点，相当于一个全局变量、函数声明)
    bool HandleTopLevelDecl(DeclGroupRef D){
//        cout<<"正在解析..."< &args) {
        return true;
    }
    
    //返回ASTConsumer类型对象，其中ASTConsumer是一个抽象类，即基类
    /*
     解析给定的插件命令行参数。
     - param CI 编译器实例，用于报告诊断。
     - return 如果解析成功，则为true；否则，插件将被销毁，并且不执行任何操作。该插件负责使用CompilerInstance的Diagnostic对象报告错误。
     */
    unique_ptr CreateASTConsumer(CompilerInstance &CI, StringRef iFile) {
        //返回自定义的CJLASTConsumer,即ASTConsumer的子类对象
        /*
         CI用于：
         - 判断文件是否使用户的
         - 抛出警告
         */
        return unique_ptr (new HKASTConsumer(CI));
    }
    
};

}

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

其原理主要分为三步

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

然后在终端中测试插件

//命令格式
自己编译的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/CJLPlugin.dylib -Xclang -add-plugin -Xclang CJLPlugin -c /Users/XXXX/Desktop/XXX/XXXX/测试demo/testClang/testClang/ViewController.m

测试插件

4、Xcode集成插件

加载插件

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

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

设置编译器

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

编译错误

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

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

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

iOS llvm-2

LLVM

传统编译器设计

ios的编译器架构

模块说明

LLVM的设计

Clang简介

LLVM编译流程

一、预处理编译阶段

二、编译阶段

1、词法分析

2、语法分析

3、生成中间代码IR

三、后端

生成汇编代码

四、生成目标文件

五、链接

六、绑定

总结

Clang插件开发

1、准备工作

2、LLVM编译

安装cmake

编译LLVM

通过xcode编译LLVM(方式一)

通过ninja编译LLVM(方式二)

3、创建插件

编写插件代码

4、Xcode集成插件

加载插件

设置编译器

你可能感兴趣的:(iOS llvm-2)