LLVM

解释性语言和编译性语言的区别？
解释性语言可以通过解释器直接执行相应的代码，比如python语言；而
编译性语言要经过编译器编译成相应的可执行文件，然后才可以执行。

传统的编译器设计

传统的编译器

编译器前端(Frontend)

编译器前端的任务是解析源代码。它会进行：词法分析，语法分析，语义分析，检查源代码是否存在错误，然后构建抽象语法树(Abstract Syntax Tree，AST)，LLVM的前端还会生成中间代码(IR)。

优化器(Optimizer)

优化器负责各种优化。改善代码的运行时间，例如消除冗余计算等。

后端(Backend)/代码生成器(CodeGenerator)

将代码映射到目标指令集，生成机器语言，并且进行机器相关的代码优化。

iOS的编译器架构

clang和llvm的联系？
Objective C/C/C++使用的编译器前端是Clang，swift是Swift。后端都是LLVM。LLVM是编译器的框架系统，clang只是编译器的前端部分。

iOS编译器架构

LLVM的设计

其他的编译器如GCC，作为了一个整体的程序设计的，所以不够灵活。
LLVM最重要的设计就是，使用的通用的代码表示形式IR，它是用来在编译器中表示代码的形式。所以LLVM可以灵活的增加前端和后端，只要增加的前端和后端使用同一的规则IR就可以。


LLVM灵活的前后端

Clang

Clang是LLVM的一个子项目，它的诞生是为了替代GCC。它属于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

上面过程的解释：
0：输入原文件；
1：预处理过程，包括宏的替换，头文件的导入等；
2：编译阶段，词法分析、语法分析，最终生成IR代码。
3：后端，代码优化处理，最终生成汇编；
4：汇编生成目标文件；
5：连接：链接需要的动态库和静态库，生成可执行文件；
6：通过不同的架构，生成对象的可执行文件；

预处理阶段
clang -E main.m

执行完成后可以看到文件的导入和宏的替换。

编译阶段

词法分析：把代码切成一个个的Token，比如大小括号，字符串等。

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

语法分析：在词法分析的基础上将单词序列组成起来，形成了语法树，判断程序代码在结构上是否正确。

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

生成中间代码：
通过下面的代码可以生成.ll的IR代码文件

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

IR生成时可以通过参数选择优化，优化级别分别为-O0 -O1 -O2 -O3 -Os

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

bitCode：Xcode7以后可通过bitcode开启进一步的优化，生成.bc的中间代码。

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

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

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

生成目标文件(汇编器)：

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

生成可执行文件(链接)：

clang main.o -o main

创建Clang插件

  • 在LLVM的目录 /llvm/tools/clang/tools 创建新的插件：HKPlugin。


    插件目录

  • 修改/llvm/tools/clang/tools目录下的CMakeLists.text文件，新增add_clang_subdirectory(HKPlugin)。


    配置文件

  • 在HKPlugin目录下新增一个HKPlugin.cpp的文件以及CMakeLists.text配置文件。在CMakeLists.text中填写配置信息：

插件的配置信息
  • 接下来我们利用cmake重新生成一下Xcode项目。在build_xcode目录下cmake -G Xcode ../llvm

  • 最后在LLVM的Xcode项目中可以看到Loadable modules 目录下有自己的Plugin目录了。下面我们就可以在里面编写插件代码了。


    自定义插件

    一个简单的插件代码：

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

    class HKConsumer : public ASTConsumer{
    public:
        //解析完一个顶级的申明就会来这里执行!
        bool HandleTopLevelDecl(DeclGroupRef D) {
            cout<<"正在解析..."<<endl;
            return true;
        }
        
        //解析完整个文件后被调用
        void HandleTranslationUnit(ASTContext &Ctx) {
            cout<<"文件解析完毕!"<<endl;
        }
        
    };


    //继承PluginASTAction实现我们自定义的Action
    class HKASTAction: public PluginASTAction{
    public:
        bool ParseArgs(const CompilerInstance &CI,
                       const std::vector<std::string> &arg){
            return true;
        }
        
        unique_ptr<ASTConsumer> CreateASTConsumer(CompilerInstance &CI,
                                                  StringRef InFile){
            return unique_ptr <HKConsumer>(new HKConsumer);
        }
        
    };


}
//注册插件
static FrontendPluginRegistry::Add<HKPlugin::HKASTAction> X("HKPlugin", "This is the description of the plugin");

测试插件代码

自己编写的clang插件目录 -isysroot /Applications/Xcode.app/Contents/Deve loper/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulat or12.2.sdk/ -Xclang -load -Xclang 插件(.dylib)路径 -Xclang -add-plugin
-Xclang 插件名 -c 源码路径

测试结果：


插件测试结果

自定义clang---属性修饰符copy

在clang的语法分析阶段，判断属性类型为NSString，NSArray，NSDictionay的，是否使用copy修饰，如果不是copy修饰报出警告。

@interface ViewController ()
/**  */
@property (nonatomic, strong) NSString *name;
/**  */
@property (nonatomic, strong) NSArray *arrs;

@end

我们使用clang的语法分析命令翻译该文件

clang -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/ iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator12.2.sdk􏱶􏲽􏲾S DK􏲿􏳀􏱷 -fmodules -fsyntax-only -Xclang -ast-dump ViewController.m

得到的了编译阶段的语法树：


语法树

可以看到属性在语法树中被翻译为ObjCPropertyDecl。我们可以在语法分析的阶段监听ObjCPropertyDecl这种类型的节点，然后进行判断。想要监听某个类型的节点，我们可以使用MatchFinder来获取。

class ZFConsumer : public ASTConsumer{
private:
    MatchFinder matcher;
    ZFMatchCallback callBack;
public:
    ZFConsumer() {
        matcher.addMatcher(objcPropertyDecl().bind("objcPropertyDecl"), &callBack);
    }
    
    //解析完整个文件后被调用
    void HandleTranslationUnit(ASTContext &Ctx) {
        cout<<"ZF文件解析完毕!"<<endl;
        matcher.matchAST(Ctx);
    }
};

为Consumer增加了成员变量matcher，在Consumer的初始化中通过matcher来添加objcPropertyDecl类型节点的监听。然后在文件解析完的回调方法HandleTranslationUnit中，为matcher传递ASTContext。另外我们还需要创建回调的对象ZFMatchCallback。

class ZFMatchCallback: public MatchFinder::MatchCallback {
public:
    virtual void run(const MatchFinder::MatchResult &Result) {
    //通过结果获取到节点。
    const ObjCPropertyDecl *propertyDecl = Result.Nodes.getNodeAs<ObjCPropertyDecl>("objcPropertyDecl");
    
    if (propertyDecl) {//如果节点有值
        //拿到属性的类型
        string typeStr = propertyDecl->getType().getAsString();
        cout<<typeStr<<"应该用copy修饰"<<endl;
    }
}
};

监听到objcPropertyDecl类型的节点后，会回调run方法。这样我们就可以获取到节点以及节点的类型等信息。
这样进行监听话，还会把引入的头文件的信息全部都给拦截监听了，所以我们需要过滤下，如果是路径包含"/Applications/Xcode.app/"就为系统的头文件中的信息，需要过滤掉。

//判断是否是自己的文件
bool isUserSourceCode(const string filename) {
    if (filename.empty()) return false;
    
    // 非Xcode中的源码都认为是用户源码
    if (filename.find("/Applications/Xcode.app/") == 0) return false;
    
    return true;
}

//获取文件名称
string filename = CI.getSourceManager().getFilename(propertyDecl->getSourceRange().getBegin()).str();
if (propertyDecl && isUserSourceCode(filename)) {//如果节点有值,并且是用户文件
  .......
}

其中的CI为CompilerInstance类型，是通过ZFConsumer传递过来的。

然后我们还需要判断当前的属性是否正确使用了copy

//判断是否应该用copy修饰。
bool isShouldUseCopy(const string typeStr) {
    if (typeStr.find("NSString") != string::npos ||
        typeStr.find("NSArray") != string::npos ||
        typeStr.find("NSDictionary") != string::npos/*...*/) {
        return true;
    }
    return false;
}

//attrKind & ObjCPropertyDecl::OBJC_PR_copy 如果实行修饰符为copy返回true
if (isShouldUseCopy(typeStr) && !(attrKind & ObjCPropertyDecl::OBJC_PR_copy)) {

}

如果该使用copy的地方没有使用copy，使用DiagnosticsEngine诊断引擎进行警告处理

//诊断引擎
DiagnosticsEngine &diag = CI.getDiagnostics();
//Report 报告
diag.Report(propertyDecl->getBeginLoc(),diag.getCustomDiagID(DiagnosticsEngine::Warning, "%0这个地方推荐用Copy"))<<typeStr;

这样我们的clang插件就写的差不多了，使用自定义的clang和clang插件对ViewController.m文件的属性就行语法检测，结果如下：

NSString *应该用copy修饰而没用Copy，发出警告！
demo1/ViewController.m:13:1: warning: NSString *这个地方推荐用Copy
@property (nonatomic, strong) NSString *name;
^
NSArray *应该用copy修饰而没用Copy，发出警告！
demo1/ViewController.m:15:1: warning: 
      NSArray *这个地方推荐用Copy
@property (nonatomic, strong) NSArray *arrs;
^
2 warnings generated.

最后附上我们自定义的clang插件的完成代码：

#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 ZFPlugin {
    
    class ZFMatchCallback: public MatchFinder::MatchCallback {
    private:
        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) {
            if (typeStr.find("NSString") != string::npos ||
                typeStr.find("NSArray") != string::npos ||
                typeStr.find("NSDictionary") != string::npos/*...*/) {
                return true;
            }
            return false;
        }
        
    public:
        ZFMatchCallback(CompilerInstance &CI):CI(CI) {}
        
        virtual void run(const MatchFinder::MatchResult &Result) {
            //通过结果获取到节点。
            const ObjCPropertyDecl *propertyDecl = Result.Nodes.getNodeAs<ObjCPropertyDecl>("objcPropertyDecl");
            //获取文件名称
            string filename = CI.getSourceManager().getFilename(propertyDecl->getSourceRange().getBegin()).str();
            
            if (propertyDecl && isUserSourceCode(filename)) {//如果节点有值,并且是用户文件
                //拿到属性的类型
                string typeStr = propertyDecl->getType().getAsString();
                //拿到节点的描述信息
                ObjCPropertyDecl::PropertyAttributeKind attrKind = propertyDecl->getPropertyAttributes();
                
                //attrKind & ObjCPropertyDecl::OBJC_PR_copy 如果实行修饰符为copy返回true
                if (isShouldUseCopy(typeStr) && !(attrKind & ObjCPropertyDecl::OBJC_PR_copy)) {
                    cout<<typeStr<<"应该用copy修饰而没用Copy，发出警告！"<<endl;
                    //诊断引擎
                    DiagnosticsEngine &diag = CI.getDiagnostics();
                    //Report 报告
                    diag.Report(propertyDecl->getBeginLoc(),diag.getCustomDiagID(DiagnosticsEngine::Warning, "%0这个地方推荐用Copy"))<<typeStr;
                }
            }
        }
    };
    
    class ZFConsumer : public ASTConsumer{
    private:
        MatchFinder matcher;
        ZFMatchCallback callBack;
    public:
        ZFConsumer(CompilerInstance &CI): callBack(CI) {
            matcher.addMatcher(objcPropertyDecl().bind("objcPropertyDecl"), &callBack);
        }
        
        //解析完整个文件后被调用
        void HandleTranslationUnit(ASTContext &Ctx) {
            cout<<"ZF文件解析完毕!"<<endl;
            matcher.matchAST(Ctx);
        }
        
    };
    
    
    //继承PluginASTAction实现我们自定义的Action
    class ZFASTAction: public PluginASTAction{
    public:
        bool ParseArgs(const CompilerInstance &CI,
                       const std::vector<std::string> &arg){
            return true;
        }
        
        unique_ptr<ASTConsumer> CreateASTConsumer(CompilerInstance &CI,
                                                  StringRef InFile){
            return unique_ptr <ZFConsumer>(new ZFConsumer(CI));
        }
        
    };
    
    
}
//注册插件
static FrontendPluginRegistry::Add<ZFPlugin::ZFASTAction> X("ZFPlugin", "This is the description of the plugin");

Xcode集成自定义插件

前面我们写好了自定义的功能插件，下面我们把插件集成到Xcode中去。

加载插件

打开测试的xcode项目，在Build Settings -> Other C Flags添加如下内容：

-Xclang -load -Xclang (.dylib)插件路径 -Xclang -add-plugin -Xclang ZFPlugin。


配置自定义插件

设置编译器

  • 设置编译器clang为自己的clang。
    clang插件需要对应版本的clang去加载，如果版本不一致会导致编译出错。需要再Build Setting中新增两项用户定义的设置


    image.png

  • 分别为CC和CXX。
    CC对应的是自己编译的clang路径；
    CXX对应的是自己编译的clang++路径；


    image.png

  • 接下来在Build Settings栏目中搜索Index，将Enable Index-While-Building Functionality的Default该为NO。


    image.png

  • 然后可以达到我们的最终目的，使用自定义的clang插件检测我们的代码的语法了。


    检测语法
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 200,527评论 5赞 470
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 84,314评论 2赞 377
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 147,535评论 0赞 332
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,006评论 1赞 272
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 62,961评论 5赞 360
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,220评论 1赞 277
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 37,664评论 3赞 392
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,351评论 0赞 254
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 40,481评论 1赞 294
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,397评论 2赞 317
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,443评论 1赞 329
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,123评论 3赞 315
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 38,713评论 3赞 303
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,801评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,010评论 1赞 255
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 42,494评论 2赞 346
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,075评论 2赞 341

推荐阅读更多精彩内容