美文网首页ios
iOS-底层原理 31:LLVM编译流程 & Clang插件开发

iOS-底层原理 31:LLVM编译流程 & Clang插件开发

作者: Style_月月 | 来源:发表于2020-11-18 00:38 被阅读0次

    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++使用的编译器前端是ClangSwiftswift,后端都是LLVM,如下图所示

    ios的编译器架构

    模块说明

    • 前端 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
    
    LLVM编译流程

    下面分别针对上述流程来解释,其中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
    

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


    编译阶段-1

    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
    

    下面是语法分析的结果


    编译阶段-2

    其中,主要说明几个关键字的含义

    • -FunctionDecl 函数
    • -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文件


    编译阶段-3

    其中,test函数的参数解释为


    编译阶段-4
    • 当然,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
    

    这是优化后的中间代码


    编译阶段-5
    • xcode7以后开启bitcode,苹果会做进一步优化,生成.bc的中间代码,我们通过优化后的IR代码生成.bc代码
    clang -emit-llvm -c main.ll -o main.bc
    

    三、后端

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

    生成汇编代码

    • 我们通过最终的.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文件的格式为汇编代码

    生成汇编代码

    四、生成目标文件

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

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

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

    $xcrun nm -nm main.o
    

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

    生成目标文件
    • _printf函数是一个是undefined 、external

    • undefined表示在当前文件暂时找不到符号_printf

    • external表示这个符号是外部可以访问

    五、链接

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

    • 静态库会和可执行文件合并

    • 动态库是独立的

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

    clang main.o -o main
    

    查看链接之后的符号

    $xcrun nm -nm main
    

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

    链接-1
    • 通过命令查看 main是什么格式,此时是 mach-o可执行文件
      链接-2

    六、绑定

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

    总结

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


    LLVM编译流程

    Clang插件开发

    1、准备工作

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

    • 下载LLVM项目
    git clone https://mirrors.tuna.tsinghua.edu.cn/git/llvm/llvm.git
    
    • LLVMprojects目录下下载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
    
    • Clangtools下安装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


        编译LLVM-1
      • 编译(CMD + B),选择ALL_BUILD Secheme进行编译,预计1+小时
        编译LLVM-2

    注:这里通过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下新建插件CJLPlugin

      创建插件-1
    • /llvm/tools/clang/tools目录下的CMakeLists.txt文件,新增add_clang_subdirectory(CJLPlugin),此处的CJLPlugin即为上一步创建的插件名称

      创建插件-2
    • CJLPlugin目录下新建两个文件,分别是CJLPlugi.cppCMakeLists.txt,并在CMakeLists.txt中加上以下代码

    //1、通过终端在CJLPlugin目录下创建
    touch CJLPlugin.cpp
    
    touch CMakeLists.txt
    
    //2、CMakeLists.txt中添加以下代码
    add_llvm_library( CJLPlugin MODULE BUILDTREE_ONLY 
        CJLPlugin.cpp
    )
    
    创建插件-3
    • 接下来利用cmake重新生成Xcode项目,在build_xcode目录下执行以下命令
    cmake -G Xcode ../llvm
    
    • 最后可以在LLVM的xcode项目中可以看到Loadable modules目录下由自定义的CJLPlugin目录了,然后可以在里面编写插件代码了
      创建插件-4

    编写插件代码

    CJLPlugin目录下的CJLPlugin.cpp文件中,加入以下代码

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

    其原理主要分为三步

    • 【第一步】注册插件,并自定义AST语法树Action类
      • 继承自PluginASTAction,自定义ASTAction,需要重载两个方法ParseArgsCreateASTConsumer,其中的重点方法是CreateASTConsumer,方法中有个参数CI即编译实例对象,主要用于以下两个方面
        • 用于判断文件是否是用户的

        • 用于抛出警告

      • 通过FrontendPluginRegistry注册插件,需要关联插件名与自定义的ASTAction类
    • 【第二步】扫描配置完毕
      • 继承自ASTConsumer类,实现自定义的子类CJLASTConsumer,有两个参数MatchFinder对象matcher以及CJLMatchCallback自定义的回调对象callback

      • 实现构造函数,主要是创建MatchFinder对象,以及将CI床底给回调对象

      • 实现两个回调方法

        • HandleTopLevelDecl:解析完一个顶级的声明,就回调一次
        • HandleTranslationUnit:整个文件都解析完成的回调,将文件解析完毕后的上下文context(即AST语法树) 给 matcher
    • 【第三步】扫描完毕的回调函数
      • 继承自MatchFinder::MatchCallback,自定义回调类CJLMatchCallback

      • 定义CompilerInstance私有属性,用于接收ASTConsumer类传递过来的CI信息

      • 重写run方法

        • 1、通过result,根据节点标记,获取相应节点,此时的标记需要与CJLASTConsumer构造方法中一致

        • 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 CJLPlugin
    
    加载插件

    设置编译器

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


      设置编译器-1
    • Build Settings栏目中新增两项用户定义的设置,分别是CCCXX

      • CC 对应的是自己编译的clang的绝对路径

      • CXX 对应的是自己编译的clang++的绝对路径

    设置编译器-2
    • 接下来在Build Settings中搜索index,将Enable Index-Wihle-Building FunctionalityDefault改为NO

      设置编译器-3
    • 最后,重新编译测试项目,会出现下面的效果


      设置编译器-4

    相关文章

      网友评论

        本文标题:iOS-底层原理 31:LLVM编译流程 & Clang插件开发

        本文链接:https://www.haomeiwen.com/subject/avszbktx.html