clang_clang版本 - CSDN
精华内容
参与话题
  • 什么是Clang?

    千次阅读 2013-02-14 09:03:58
    Clang项目的目标是创建一个新的C,C++,Objective C和Objective C++编译器(译注:也就是LLVM的前端Front-end,可参见snsn1984的博客),Clang基于LLVM架构,你现在可以获取它的源代码进行构建。 特性和目标 ...

    译者:蓝白云

    Clang: 一种C语言家族编译器

    Clang项目的目标是创建一个新的C,C++,Objective C和Objective C++编译器(译注:也就是LLVM的前端Front-end,可参见snsn1984的博客),Clang基于LLVM架构,你现在可以获取它的源代码进行构建。


    特性和目标

    最终用户:

    • 更快速的编译和低内存占用
    • 更易用的编译错误和警告信息表达 (参见例子)
    • GCC兼容

    二次应用:

    • 基于库的模块化架构设计
    • 支持多样化的客户程序 (重构, 静态分析, 代码生成等)
    • 允许与IDE紧密集成
    • 采用了比较开放的类BSD协议(LLVM 'BSD' License)

    内部设计和实现(Clang开发者本身):

    • 一个真正的产品级质量编译器
    • 简单易被理解代码库
    • 统一的解释器(C, Objective C, C++, 和Objective C++)
    • 保持与C/C++/ObjC等类C语言的一致性

    当然上面这些是一个粗略的目标和特性。想全面了解Clang,请参见这里,它将描述得更加详细。


    为什么需要Clang?

    软件开发需要一种新的编译器:可以更好的诊断和提示编译错误和警告信息更好集成开发环境(IDE)整合以及更加灵活容易开发和维护商业友好的编译器这些就是开启新的前端(Front-end)编译器动机

    下面一些很好的(但确实很过时了)介绍Clang视频讲座

    如需更详细的Clang和其他编译器的比拼信息参阅Clang的比拼


    当前状态

    Clang处于开发状态。Clang定义为一个CObjective-CC++Objective C++产品级质量编译器支持X86-32X86-64ARM其他目标可能警告通常很容易解决如果您正在寻找代码分析“源代码到代码”的转换工具Clang可能是的最佳解决方案Clang也支持C ++11有关更多信息,请参阅C ++状态


    如何获取Clang和参与其中

    这里是获取Clang的代码,构建和运行它的第一手资料:希望它会与你产生共鸣:)

    一旦你这样做了,考虑参与Clang开发社区中来Clang开发社区中包括了许多各种不同背景的志愿者以及他们所贡献的资源之后的开发中,如果你有兴趣了解Clang项目如何工作订阅邮件列表一个很好的方式


    展开全文
  • clang的使用

    千次阅读 2019-05-30 15:09:18
    介绍:Clang Static Analyzer建立在Clang和LLVM之上。严格来说,分析器是Clang的一部分,因为Clang包含一组可重用的C ++库,用于构建强大的源代码级工具。Clang Static Analyzer使用的静态分析引擎是一个Clang库,...

    介绍:Clang Static Analyzer建立在ClangLLVM之上。严格来说,分析器是Clang的一部分,因为Clang包含一组可重用的C ++库,用于构建强大的源代码级工具。Clang Static Analyzer使用的静态分析引擎是一个Clang库,可以在不同的上下文和不同的客户端中重用。

     

    llvm+clang的源码安装:【采用这样的安装方式,而不是采用install 预编译的包(apt-get install方式)。这样就能获得源码的文件组织架构,方便扩充自己的检查规则。而安装预编译的包只能获得编译后的二进制,没有文件的组织架构。】

    https://www.cnblogs.com/Long-w/p/6345028.html

    clang静态检测:http://clang-analyzer.llvm.org/

    checker的开发手册:http://clang-analyzer.llvm.org/checker_dev_manual.html

    入门【用来调试开发的checker】

    • 要查看源代码并构建项目,请按照Clang入门 页面的步骤1-4进行操作。
    • 分析器源代码位于Clang源代码树下: 
      cd llvm / tools / clang 
      请参阅:include / clang / StaticAnalyzer,lib / StaticAnalyzer, test / Analysis。
    • 分析器回归测试可以从Clang的构建目录中执行: 
      cd ../../../; cd build / tools / clang; TESTDIRS =分析进行测试
    • 使用指定的检查器分析文件: 
      clang -cc1 -analyze -analyzer-checker = core.DivideZero test.c
    • 列出可用的检查器: 
      clang -cc1 -analyzer-checker-help
    • 有关不同的输出格式,微调和调试选项,请参阅分析器帮助: 
      clang -cc1 -help | grep“analyzer”

    对整个工程进行静态检测:http://clang-analyzer.llvm.org/scan-build.html

    展开全文
  • clang static analyzer源码分析(一)

    万次阅读 热门讨论 2017-08-06 16:55:55
    引子clang静态代码分析是clang相对于gcc一个比较能够引起关注的点,特别是clang静态代码分析基于checker的架构和大部分的静态分析工具都不相同。clang静态代码分析使用符号执行的技术执行路径敏感的代码分析,符号...

    引子

    clang静态代码分析是clang相对于gcc一个比较能够引起关注的点,特别是clang静态代码分析基于checker的架构和大部分的静态分析工具都不相同。clang静态代码分析使用符号执行的技术执行路径敏感的代码分析,符号执行引擎并不实际进行报错,而是使用挂载在引擎上的checker对程序状态进行检查并报错。这种方式方便用户对代码检查规则或者bug类型进行扩展,但是这种架构也有其缺陷,符号执行完成一条语句后,clang静态分析引擎会遍历checker列表中的回调函数进行报错,也就是说checker的数量越多,clang静态分析扫描代码的速度越慢(clang静态分析引擎的速度是不变的)。

    下面我们会通过源码分析的方式来揭示clang静态代码扫描的整体流程。关于clang静态分析的使用毋庸多言,可以查看官方文档例如scan-build: running the analyzer from the command lineClang Static Analyzer。下面我们进入正体,开始源码的阅读之旅!


    AnalysisConsumer

    This header contains the functions necessary for a front-end to run various analyses.

    从Clang源码给出的注释我们可以看到,AnalysisConsumer.h是关于clang是如何调用其代码分析接口的,这个类的定义如下代码所示:

    class AnalysisASTConsumer : public ASTConsumer {
    public:
        virtual void AddDiagnosticConsumer(PathDiagnosticConsumer *Consumer) = 0;
    };
    
    /// CreateAnalysisConsumer - Creates an ASTConsumer to run various code 
    /// analysis passes. (The set of analyses run is controlled by command-line options.)
    std::unique_ptr<AnalysisASTConsumer>
    CreateAnalysisConsumer(CompilerInstance &CI);

    AnalysisASTConsumer继承自ASTConsumer,是一个虚基类,只提供了一个添加报错机制的纯虚函数。

    clang静态分析checker提供了两种方法,一种是遍历AST进行语法层级的报错,例如位运算符的操作数是有符号整数等,这些直接从AST树上拿到相关信息就可以直接报错,另外一种是需要构建CFG并在其上进行符号执行实现路径敏感的代码分析,关于这个,就有人曾经问过我,clang静态分析中CFG和AST的关系是什么。现在我们从这个类的继承体系就可以看出,clang静态代码分析是继承自于ASTConsumer,也就是说无论是基于AST的检查还是基于CFG的检查都是在AST上实现的,因为构建CFG也需要AST的协助。

    /// ASTConsumer - This is an abstract interface that should be implemented by
    /// clients that read ASTs. This abstraction layer allows the client to be independent of the AST producer.

    class ASTConsumer {
    // …
    };

    但是AnalsisASTConsumer并不是真正执行代码分析的类,该类只是提供一个接口,真正实现代码分析的类是AnalysisConsumer,该类的定义如下:

    class AnalysisConsumer : public AnalysisASTConsumer, 
                            public RecursiveASTVisitor<AnalysisConsumer> {
        enum {
            AM_None = 0,
            AM_Syntax = 0x1,
            AM_path = 0x2
        };
        typedef unsigned AnalysisMode;
        // ...
    public:
        ASTContext *Ctx;
        AnalyzerOptionsRef Opts;
    
        /// \brief Stores the declarations from the local translation unit.
        SetOfDecls LocalTUDecls;
    
        // Set of PathDiagnosticConsumers. Owned by AnalysisManager.
        PathDiagnosticConsumers PathConsumers;
    
        StoreManagerCreator CreateStoreMgr;
        ConstraintManagerCreator CreateConstraintMgr;
    
        std::unique_ptr<CheckerManager> checkerMgr;
        std::unique_ptr<AnalysisManager> Mgr;
    
        /// Time the analyzes time of each translation unit.
        static llvm::Timer* TUTotalTimer;
    
        /// The information about analyzed functions shared throughout the
        /// translation unit.
        FuntionSummariesTy FunctionSummaries;
    };

    AnalysisConsumer 继承自 AnalysisASTConsumer 和 RecursiveASTVisitor ,其中AnalysisASTConsumer我们已经介绍过就是一个接口,而RecursiveASTVisitor 则是一个clang提供的一个遍历AST的类,这个类提供了很方便的遍历AST的接口。如果我们想遍历AST并作相关操作的话,我们都需要继承这个类,注意这个类使用的是静态多态(CRTP),LLVM为了提高运行效率和减少内存占用,在编译时默认关闭了RTTI选项,所以LLVM的多态没有使用C++提供的基于虚表的多态技术而是使用CRTP。言归正传,AnalysisConsumer继承自RAV是为了支持遍历AST来进行语法层级的代码检查。

    AnalysisConsumer下面定义了一个表示代码分析模式的枚举类型,分别有AM_NoneAM_SyntaxAM_Path,这三个模式分别表示不进行代码分析,进行语法层级的代码分析,进行路径敏感的代码分析。这三个模式很重要,决定着我们调用clang静态代码分析引擎的时候,会进行哪些代码分析。

    下面定义了ASTContext类型的数据成员,ASTContext是保存AST相关信息的类,由于静态代码分析有些情况下是会需要到这些信息的。类ASTContext注释信息如下:

    /// \brief Holds long-lived AST nodes (such as types and decls) that referred to throughout the semantic analysis of a file.
    class ASTContext : public RefCountedBase<ASTContext> {
    };

    下面定义了AnalyzeOptionsRef类型的数据成员Opts,该成员表示调用静态代码分析时相关的调用参数。后面的LocalTUDecls数据成员表示该编译单元中的所有声明。后面的PathConsumers用以表示代码分析时的报错相关的对象。

    而其中的CreateStoreMgr需要着重说一下,静态分析的过程中,需要沿着CFG进行符号执行,而在符号执行的过程中需要时刻维护相关状态信息(例如某个表达式的符号值或者某个变量的约束),所以需要使用一个StoreManager去维护符号执行过程中的值信息。下面的CreateConstraintMgr也和静态分析相关,因为沿着CFG进行符号执行的过程中,需要进行路径的约束判断,静态代码分析本来就存在着路径爆炸的问题,所以需要使用一个ConstraintManager来维护相关约束,并进行约束求解。插一句题外话,虽然数据流分析也需要考虑全路径,但是毕竟数据流分析关注的是一些简单的属性信息,有时候这些属性信息使用一个位向量就能表示,所以对内存要求并不高,而且数据路分析需要考虑全路径以保证安全性。

    下面的checkerMgr是用于管理静态分析所注册的checker的,其中定义了很多关于程序点的检查函数例如,runCheckersForPostStmt()这个函数表示在静态分析时,在每个语句符号执行之前都会调用这个函数。checker及其方法的注册是在LLVM(Clang Static Analyzer)编译时完成的,每次添加一个自己写的checker都需要在checkers.td中添加注册信息,然后重新编译,编译后的Clang Static Analyzer中就注册了新添加的Checker信息。另外关于checker有哪些回调函数,可以在Checker.h中查找,例如checkPreCall以及checkPostCall等回调方法,当然你可以添加自定义的回调,现在关于AM_Syntax层级的检查只有Visit*Decl()的方法,你可以添加自定义的回调类型,例如Visit*Stmt(),然后约定好如何注册这些方法,然后在后面的AM_Syntax的检查中,就可以调用该回调。现今关于AM_Syntax语句的检查一般是通过StmtVisitor接口实现的,定位到例如FunctionDecl()中以后,调用StmtVisitor遍历该方法的函数体。

    后面还定义了用于clang静态分析的计时器TuTotalTimer,用于记录静态分析某个文件所花的时间。另外该类还定义了FunctionSummaries,用于记录静态分析时所有函数的函数“摘要”信息,该摘要信息仅仅用于记录静态分析时函数的某些特性,例如有多少个基本块,该函数在此前的静态分析中被inline了多少次等等信息。

    AnalysisConsumer - HandleTranslationUnit

    前面我已经介绍过了AnalysisConsumer是整个静态分析最基本的类,该类用于接收用户输入的相关参数并调用相关方法来进行静态分析。其中当属HandleTranslationUnit(ASTContext &C),这个方法用于处理这个编译单元的静态分析工作,是整个静态分析的总括性方法。该方法定义如下所示:

    void AnalysisConsumer::HandleTranslationUnit(ASTContext &C) {
        // Don't run the actions if an error has occurred with parsing the file.
        DiagnosticsEngine &Diags = PP.getDiagnostics();
        if (Diags.hasErrorOccurred() || Diags.hasFatalErrorOccurred())
        return;
    
        // Don't analyze if the user explicitly asked for no checks to be performed
        // on this file
        if (Opts->DisableAllChecks)
            return;
    
        {
            if (TuTotalTimer) TuTotalTimer->startTimer();
    
            // Introduce a scope to destroy BR before Mgr.
            BugReporter BR(*Mgr);
            TranslationUnitDecl *TU = C.getTranslationUnitDecl();
            checkerMgr->runCheckersOnASTDecl(TU, *Mgr, BR);
    
            // Run the AST-only checks using the order in which functions are defined.
            // If inlining is not turned on, use the simplest function order for path
            // sensitive analyzes as well.
            RecVisitorMode = AM_Syntax;
            if (!Mgr->shouldInlineCall())
                RecVisitorMode |= AM_Path;
            RecVisitorBR = &BR;
    
            // Process all the top level declarations/
            //
            const unsigned LocalTUDeclsSize = LocalTUDecls.size();
            for (unsigned i = 0; i < LocalTUDeclsSize; ++i) {
                TraverseDecl(LocalTUDecls[i]);
            }
    
            if (Mgr->shouldInlineCall())
                HandleDeclsCallGraph(LocalTUDeclsSize);
    
            // After all decls handled, run checkers on the entire TranslationUnit.
            checkerMgr->runCheckersOnEndOfTranslationUnit(TU, *Mgr, BR);
    
            RecVisitorBR = nullptr;
        }
    
        // Explicitly destroy the PathDiagnosticConsumer.  This will flush its output.
        Mgr.reset();
    
        if (TUTotalTimer) TUTotalTimer->stopTimer();
    
        // Count how many basic blocks we have not covered.
        NumBlocksInAnalyzedFunctions = FunctionSummaries.getTotalNumBasicBlocks();
        if (NumBlocksInAnalyzedFunctions > 0)
            PercentReachableBlocks =                    (FunctionSummaries.getTotalNumVisitedBasicBlocks() /
        NumBlocksInAnalyzedFunctions;
    }

    这个方法前面获取前端编译的 DiagnosticsEngine ,clang前端编译时就是通过这个对象报错的,该类的注释信息如下。也就是说如果这个代码出现编译错误,会直接退出,不会进行静态代码分析,这个算是clang静态代码分析的一个不足,只有前端编译通过的代码才会进行静态代码分析。

    /// \brief Concrete class used by the front-end to report problems and issues.
    /// 
    /// This massages the diagnostics (e.g. handling things like "report warnings
    /// as errors" and passes them off to the DiagnosticConsumer for reporting to
    /// the user. DiagnosticsEngine is tied to one translation unit and one
    /// ourceManager.
    class DiagnosticsEngine : public RefCountedBase<DiagnosticsEngine>
        // ...
        enum Level {
            Ignored = DiagnosticIDs::Ignored,
            Note = DiagnosticIDs::Note,
            Remark = DiagnosticIDs::Remark,
            Warning = DiagnosticIDs::Warning,
            Error = DiagnosticIDs::Error,
            Fatal = DiagnosticIDs::Fatal
        };
    };

    下面该方法判断是否禁用了所有checker(Opts->DisableAllChecks),如果禁用了所有checker,则不进行代码分析,直接退出。

    后面括号中的代码进行静态代码分析前的一些初始化工作,例如开启计时功能,定义BugReporter对象用于报错。获取编译单元的声明TranslationUnitDecl,并在整个静态代码分析开始之前,运行针对整个编译单元声明的checker(checkerMgr->runCheckersOnASTDecl(TU, *Mgr, BR);),因为有可能某些规则需要在整个编译单元上进行检查。

    后面设置代码分析的模式,默认是AM_Syntax(也就是0x1),如果代码分析的选项中没有设置了InlineCall模式,则将代码分析模式设置为0x3,后面我们将会分析这个设置的作用。下面这个 for 循环是整个代码分析的重点,

    for (unsigned i = 0; i < LocalTUDeclsSize; ++i) {
        TraverseDecl(LocalTUDecls[i]);
    }

    这个for循环会遍历整个编译单元的语法树,并调用相应的回调函数进行代码分析。注意这个调用并没有考虑函数的调用关系,也就是说按照遍历语法树的顺序(深度优先)来调用回调函数,然后在回调函数中对对应代码进行代码分析。例如 VisitFunctionBody() ,这个函数就会对该函数对应的函数体进行代码分析。后面我们会介绍到clang静态分析的两种情况,一种是针对语法层面的(AM_Syntax)一种是在CFG上路径敏感的代码分析(AM_Path),只是这种敏感的代码分析没有考虑到整个调用图

    ===========补充=============
    AnalyzerOptions.h中有一些关于分析的选项设置,如果其中的IPAKind被设置成为IPAK_None,也就是不进行过程间的分析,此时在HandleTranslationUnit()中“if (!Mgr->shouldInlineCall())”就会返回true,此时RecVisitorMode就变成AM_Syntax | AM_Path,也就是此时会进行两种分析语法层级路径敏感,这两种分析是在TraverseDecl()->VisitFunctionDecl()->HandleCode()方法中进行的(我们会在文章后面部分看到HandleCode()方法),只是此时不会进行过程间的分析,也就是后面的HandleDeclsCallGraph()不会被调用(也就是不会进行过程间的路径敏感的分析)。但是如果AnalyzerOptions.h中的IPAKind设置成其他的类型,例如IPAK_Inlining或者IPAK_BasicInlining,那么HandleTranslationDecl()中的”if (!Mgr->shouldInlineCall())“就会返回false,此时RecVisitorMode就只是AM_Syntax,那么在后面的遍历语法树TraverseDecl()->VisitFunctionDecl()->HandleCode()的过程中就只会进行AM_Syntax的分析,而真正的路径敏感的分析则会推迟到后面的HandleDeclsCallGraph()中进行,建立函数调用图,然后按照拓扑序进行过程间的路径敏感的分析。
    PS:如果IPAMode被设置成为”IPAK_NotSet”,那么就真的只有AM_Syntax的分析了
    ==========补充==============
    然后下面的代码实现在InlineCall情况下的代码分析,这种分析首先会构建函数调用图(CallGraph),然后按照函数调用图的拓扑顺序来进行代码分析。注意,这种代码分析会按照caller->callee的顺序来进行,而且如果一个函数在之前被inline分析过,后面就不会在分析该函数。这个函数是进行AM_Path分析的入口。后面我们会详细介绍这个方法。

    if (Mgr->shouldInlineCall())
        HandleDeclsCallGraph(LocalTUDeclsSize);

    在所有代码都分析完成之后,然后再调用针对 EndOfTranslationUnit 的checker,也就是在代码结尾进行调用的checker。后面会统计时间信息和CFG基本块的到达率等信息,不再详细介绍。


    AnalysisConsumer - Visit*()

    前面我们介绍过有一种TraverseDecl()的方式进行代码分析,这种方法通过遍历AST树,然后对遍历到的每个AST结点调用对应的回调函数进行代码分析。我们简要罗列一些这些回调函数都有哪些。

    /// Handle callbacks for arbitrary Decls
    bool VisitDecl(Decl* D);
    
    bool VisitFunctionDecl(FunctionDecl *FD);
    
    bool VisitObjCMethodDecl(ObjCMethodDecl* MD);
    
    bool VisitBlockDecl(BlockDecl* BD);

    下面我们依次介绍这些方法。

    VisitDecl(Decl* D)

    这个方法在任遍历到语法树上任何声明时都会停下来,并且只进行语法层级的代码检查(AM_Syntax),该方法的定义如下:

    /// Handle callbacks for arbitrary Decls.
    bool VisitDecl(Decl *D) {
        AnalysisMode Mode = getModeForDecl(D, RecVisitorMode);
        if (Mode & AM_Syntax)
            checkerMgr->runCheckersOnASTDecl(D, *Mgr, *RecVisitorBR);
        return true;
    }

    VisitFunctionDecl(FunctionDecl* FD)

    该方法应该是AnalysisConsumer中一个比较重要的方法,该方法会对函数体进行代码分析,因为程序执行的主体就是函数,就是代码,就是指令。该函数代码如下:

    bool VisitFunctionDecl(FunctionDecl *FD) {
        IdentifierInfo *II = FD->getIdentifier();
        if (II && II->getName().startswith("__inline"))
            return true;
        // We skip function template definitions, as their semantics is
        // only determined when they are instantiated.
        if (FD->isThisDeclarationADefinition() &&
                !FD->isDependentContext()) {
            assert(RecVisitorMode == AM_Syntax || Mgr->shouldInlineCall() == false);
            HandleCode(FD, RecVisitorMode);
        }
        return true;
    }

    该方法首先会判断函数是否为inline函数,是inline函数的话,就直接退出(属个人猜测,函数声明以”__inline”开头应该表明该函数必为inline函数)。然后跳过模板,最后进行函数体的代码分析,会调用 HandleCode 函数进行函数体的代码分析。

    VisitBlockDecl(BlockDecl *BD)

    这个方法用于检查 BlockDecl (虽然以前我也不知道BlockDecl是啥),下面是 BlockDecl 的注释信息。

    /// BlockDecl - This represents a block literal declaration, which is like an
    /// unnamed FunctionDecl.  For example:
    /// ^{ statement-body }   or   ^(int arg1, float arg2){ statement-body }
    class BlockDecl : public Decl, public DeclContext {
    };

    这个方法和VisitFunctionDecl()相似,我们就不详细介绍了。


    AnalysisConsumer - HandleDeclsCallGraph()

    这个方法是用于在静态分析模式为 InlineCall 进行代码分析的,该方法其实相当于从 main 函数开始,通过静态代码分析的方式,”模拟”程序的整个执行流程,其实和虚拟机很相似。如果没有 main 函数的话,会找到函数调用图(CallGraph)中拓扑顺序最靠前的函数开始依次分析。
    注:现今的LLVM,在创建CallGraph的时候,受限于函数指针而无法分析使用函数指针进行的函数调用

    /// \brief Build the call graph for all the top level decls of this TU and
    /// use it to define the order in which the functions should be visited.
    void AnalysisConsumer::HandleDeclsCallGraph(const unsigned LocalTUDeclsSize) {
        // Build the Call Graph by adding all the top level declarations to the graph.
        CallGraph CG;
        for (unsigned i = 0; i < LocalTUDeclsSize; ++i) {
            CG.addToCallGraph(LocalTUDecls[i]);
        }
        // Walk over all of the call graph nodes in topological order, so that we
        // analyze parents before the children. Skip the functions inlined into
        // the previously processed functions. Use external Visited set to identify
        // inlined functions. The topological order allows the "do not reanalyze
        // previously inlined function" performance heuristic to be triggered more
        // often.
        SetOfConstDecls Visited;
        SetOfConstDecls VisitedAsTopLevel;
    
        llvm::ReversePostOrderTraversal<clang::CallGraph*> PROT(&CG);
        for (llvm::ReversePostOrderTraversal<clang::CallGraph*>::rpo_iterator
                I = RPOT.begin(), E = RPOT.end(); I != E; ++I) {
            NumFunctionTopLevel++;
    
            CallGraphNode *N = *I;
            Decl *D = N->getDecl();
    
            // Skip the abstract root node
            if (!D)
                continue;
            // Skip the functions which have been processed already or previously
            // inlined
            if (shouldSkipFunction(D, Visited, VisitedAsTopLevel))
                continue;
            // Analyze the function
            SetOfConstDecls VisitedCallees;
    
            HandleCode(D, AM_Path, getInliningModeForFunction(D, Visited),
            (Mgr->options.InliningMode == All ? nullptr : &VisitedCallees));
    
            // Add the visited callees to the global visited set.
            for (const Decl *Callee : VisitedCallees)
                // Decls from CallGraph are already canonical. But Decls coming from
                // CallExprs may be not. We should canonicalize them manually.
            Visited.insert(isa<ObjCMethodDecl>(Callee) ? Callee
                    : Callee->getCanonicalDecl());
            VisitedAsTopLevel.insert(D);
        }           
    }

    该方法的第6~9行代码构建函数调用图,Clang函数调用图的构建我们就不详细介绍了,大概思想就是遍历给定函数的函数体,然后定位到call site然后再向外传播构建,如果对函数调用图构建感兴趣的话可以参见CGBuiler

    后面定义两个集合用于存储 inline 分析过的函数,VisitedVisitedAsTopLevel,然后按照caller和callee的顺序来进行代码的分析。如果发现当前的函数已经通过 inline 分析过,则直接跳过。如果没有分析过,则调用 HandleCode 进行AM_Path代码分析。然后将分析过的代码加入 Visited 集合。

    注意:调用HandleCode()时的参数是 HandleCode(D, AM_Path, …),也就是说进行的是路径敏感的代码分析。

    如下图所示:

    这里写图片描述

    代码分析首先会扫描函数 A ,然后按照顺序依次扫描 B 以及 C 等。例如图中的函数 E 已经在分析 A 时 inline 过,那么就不再分析函数E。

    Clang的开发者邮件列表上曾经推过一个bug,代码如下:

    // test.cpp
    int foo(int len) {
        int j = 0;
        if (len < 10)
            j = 42 / j;
        return j;
    }

    当test.cpp中只有foo一个函数的时候能够报出除零错误,

    tu.cpp:6:10: warning: Division by zero
                    j = 42 / j;
                        ~~~^~~

    但是当代码改为如下的形式时,这个错误就不会再报出来了。因为在CallGraph中使用拓扑序进行函数的分析,所以下面这段代码就是先分析函数bar(),然后再分析函数foo(),由于bar()在调用函数foo()的时候 “if(len < 10)” 是分支失败的,所以 “j = 42 / i” 这条语句并没有被执行。

    The reason warning does not appear is that function is not analyzed out of context if it was inlined before.

    注:虽然被inline过分析的函数不会被单独进行out-of-context的分析,但是如果该函数可能在其他路径被调用,还是允许被inline的。

    // test.cpp
    int foo(int len) {
        int j = 0;
        if (len < 10)
            j = 42 / j;
        return j;
    }
    
    void bar() {
        int m = 12;
        foo(m);
    }

    这个bug就反映出clang静态代码分析的一些不足,这个邮件见这里


    AnalysisConsumer - HandleCode()

    在前面很多地方我们碰到过,例如在 VisitFunctionDecl(FunctionDecl *FD) 中,我们就提到过该函数是对函数体进行静态代码分析的函数,同样我们在通过函数调用图进行静态代码分析的时候也碰到过该函数。下面我们就着重分析一下该函数,HandleCode()的定义如下。

    /// \brief Run analyzes(syntax or path sensitive) on the given function.
    /// \param Mode - determines if we are requesting syntax only or path
    /// sensitive only analysis.
    /// \param VisitedCallees - The output parameter, which is populated with the
    /// set of functions which should be considered analyzed after analyzing the
    /// given root function.
    void HandleCode(Decl *D, AnalysisMode Mode,
                    ExprEngine::InliningModes IMode,
                    SetOfConstDecls *VisitedCallees) {
        if (!D->hasBody())
            return;
        Mode = getModeForDecl(D, Mode);
        if (Mode == AM_Mode)
            return;
        DisplayFunction(D, Mode, IMode);
        CFG *DeclCFG = Mgr->getCFG(D);
        if (DeclCFG) {
            unsigned CFGSize = DeclCFG->size();
            MaxCFGSize = MaxCFGSize < CFGSize ? CFGSize : MaxCFGSize;
        }
            // Clear the AnalysisManager of old AnalysisDeclContexts.
            Mgr->ClearContexts();
            BugReporter BR(*Mgr);
    
            if (Mode & AM_Syntax)
                checkerMgr->runCheckersOnASTBody(D, *Mgr, BR);
            if ((Mode & AM_Path) && checkerMgr->hasPathSensitiveCheckers()) {
                RunPathSensitiveChecks(D, IMode, VisitedCallees);
                if (IMode != ExprEngine::Inline_Minimal)
                    NumFunctionsAnalyzed++;
            }
    }

    HandleCode()函数根据注释的含义就可以明白,该函数使用来对函数体进行代码分析的。并且静态分析当前函数情况下,如果有些函数也被inline分析过,那么就把这些函数加入 SetOfConstDecls

    如果没有函数体,则直接返回,如果当前的静态分析Mode是 AM_Mode 则直接返回,在getModeForDecl()中会对函数进行简单的判断,例如其中会判断该函数是否是在头文件中,isSystemHeader()。然后根据当前的Decl临时构建CFG图,然后再改CFG图上进行代码分析。后面我们会清理Mgr相关信息,因为每个函数都要单独进行分析。

    注:对于忽视头文件函数的分析,Clang Static Analyzer使用suppress的概念进行表示,除此之外对leak type的bug也会进行suppress。见Clang: Suppress static analysis of system header files
    By default, the analyzer does not analyze code in ANY headers, system or otherwise, with the idea that you don’t want to see warnings in every file that includes the header. The exception to this rule is inlined functions that come from headers, and in that case you definitely do not want to ignore the header!

    下面的几行代码是极为重要的,如果当前Mode & AM_Syntax 为真,则进行语法层级的代码检查,也就是说Mode是 0x1 (只有语法层级的检查)或者 0x3 (有语法层级的检查,并且路径敏感的不是inline模式)都是可以的。如果当前Mode & AM_Path 为真,则会在CFG上进行路径敏感的代码分析,也就是说Mode是 0x2(只有AM_Path,这是不可能的,因为首先AM_Mode = AM_Syntax) 或者 0x3 (有语法层级的检查,并且路径敏感的不是inline模式)的情况下都是可以的。

    也就是说语法层级的代码检查都是会执行的,但是inline模式的路径敏感检查和非inline模式的代码检查只能执行一种,是否执行的依据就是AM_Mode。

    其中关于代码分析最重要的函数时 runCheckerOnASTBody()RunPathSensitiveChecks(),我们会在以后的文章中分析函数 RunPathSensitiveChecks(),这个函数会调用代码分析引擎进行真正的代码分析。


    CheckerManager- runCheckersOn*()

    runCheckersOn*()是 CheckerManager 提供的用于在指定声明上运行 checker 的方法。Clang提供了一系列这样的方法,如下所示。这些方法都是为了实现在 AST 上进行语法层级的检查。

    runCheckersOnASTDecl();
    runCheckersOnASTBody();
    runCheckersOnEndOfTranslationUnit();

    下面我们依次对这些方法进行分析。

    CheckerManager - runCheckersOnASTDecl()

    这个方法运行作用于 ASTDecl 上的checker,该方法的源代码如下所示:

    //===----------------------------------------------------------------------===//
    // Functions for running checkers for AST traversing..
    //===----------------------------------------------------------------------===//
    void CheckerManager::runCheckersOnASTDecl(const Decl* D, AnalysisManager& mgr,
                            BugReporter &BR) {
        assert(D);
    
        unsigned DeclKind = D->getKind();
        CachedDeclCheckers *checkers = nullptr;
        CachedDeclCheckersMapTy::iterator CCI = CachedDeclCheckersMap.find(DeclKind);
        if (CCI != CachedDeclCheckersMap.end()) {
            checkers = &(CCI->second);
        } else {
            // Find the checkers that should run for this Decl and cache them.
            checkers = &CachedDeclCheckersMap[DeclKind];
            for (unsigned i = 0, e = DeclCheckers.size(); i != e; ++i) {
                DeclCheckersInfo &info = DeclCheckers[i];
                if (info.IsDorDeclFn(D))
                    checkers->push_back(info.CheckFn);
            }
        }
        assert(checkers);
        for (CachedDeclCheckers::iterator 
                I = checkers->begin(), E = checkers->end(); I != E; ++I)
            (*I)(D, mgr, BR);
    }

    这个方法就是遍历checker列表,找到针对这个DeclKind的checker里的回调函数,然后运行这些回调函数。首先定义 CachedDeclCheckers 类型的 checkers 数据成员,这个数据成员用于存储处理此类型Decl的回调函数。

    typedef SmallVector<CheckDeclFunc, 4> CachedDeclCheckers;
    
    // Functions used by the registration mechanism, checkers should not touch
    // these directly.
    typedef CheckerFn<void (const Decl *, AnalysisManager&, BugReporter &)>
            CheckerDeclFunc;

    我们可以发现 CachedDeclCheckers 就是一组用于处理Decl的回调函数指针。

    后面我们从这些回调函数中找到针对这些Decl的回调函数,然后依次调用这些回调函数。其中这些 Checker 和回调函数都是由CheckerManager来组织的。调用这些checker的示意图如下:

    这里写图片描述

    CheckerManager - runCheckersOnASTBody()

    这个方法和 runCheckersOnASTDecl() 很相似,都是获取相应的回调函数,来进行代码分析,只是这个方法用于分析函数体。代码就不详述了,参加 runCheckersOnASTBody()

    CheckerManager - runCheckersOnEndOfTranslation()

    这个方法和 runCheckersOnASTDecl() 也很相似,也是获取相应的回调函数,来进行分析,这个方法呢用于这个编译单元都分析完成完成之后,调用这个回调函数。这个方法的函数体参见 runCheckersOnEndOfTranslation()

    总结AnalysisConsumer

    这个类的总体流程就是根据 scan-build 或者 -cc1 调用参数来安排静态分析流程,比如根据前端的参数是用于语法层级的检查或者用于路径敏感的分析。其中路径敏感的分析又分为两种,一种是在非inline模式下路径敏感的代码分析,这种方法直接遍历AST不会考虑函数的调用关系;一种是在inline模式下路径敏感的代码分析,这种方法会首先构建函数调用图。这两种分析是独立开的,首先在AST树上执行AM_Syntax级别的代码分析,然后构造CallGraph执行AM_Path级别的代码分析。整体流程如下图所示:

    这里写图片描述

    在后面的文章中我们会详细分析clang的静态分析引擎是如何在CFG上进行路径敏感的代码分析的,也就是在CFG上的符号执行技术。

    展开全文
  • Clang学习历程 概述

    千次阅读 2018-12-28 15:39:46
    Clang Clang是LLVM(Low Level Virtual Machine)项目提供的工具链中的编译器的前端部分 LLVM项目是模块化和可重用的编译器和工具链技术的集合,LLVM的一大特色就是,有着独立的、完善的、严格约束的中间代码表示。这种...

    介绍

    Clang

    ClangLLVM(Low Level Virtual Machine)项目提供的工具链中的编译器的前端部分

    LLVM项目是模块化和可重用的编译器和工具链技术的集合,LLVM的一大特色就是,有着独立的、完善的、严格约束的中间代码表示。这种中间代码,就是LLVM的字节码,是LLVM抽象的精髓,前端生成这种中间代码,后端自动进行各类优化分析,让用LLVM开发的编译器,都能用上最先见的后端优化技术。

    编译器编译流程如下

    编译流程

    来自《编译原理》

    编译器分成前端与后端两部分

    前端负责处理源代码,后端负责生成目标代码


    来自参考链接3

    环境

    macOS Hign Sierra 10.13.6
    Xcode10.1

    编译

    获取llvm源代码

    % git clone https://git.llvm.org/git/llvm.git/
    

    获取Clang源代码

    % cd llvm/tools
    % git clone https://git.llvm.org/git/clang.git/
    

    获取compiler-rt源代码

    ## 定位到llvm工程目录下
    % cd llvm
    % git clone https://git.llvm.org/git/compiler-rt.git/
    

    获取libomp源代码

    % cd llvm
    % git clone https://git.llvm.org/git/openmp.git/
    

    获取libcxxlibcxxabi源代码

    % cd llvm
    % git clone https://git.llvm.org/git/libcxx.git/
    % git clone https://git.llvm.org/git/libcxxabi.git/
    

    获取测试用例

    % cd llvm
    % git clone https://git.llvm.org/git/test-suite.git/
    

    Clang 使用CMake(一个用于构建,测试和打包软件的开源跨平台工具系列)进行构建

    # LLVM 禁止源码内编译(in-tree build is not supported),创建一个与llvm工程同级的build目录
    % cd src/
    % mkdir build
    % cd build 
    
    ## 安装cmake
    % brew install cmake
    
    ## -G <generator-name>
    ##             Specify a build system generator.
    ## cmake [{-D <var>=<value>}...] -P <cmake-script-file>
    ## Create or update a cmake cache entry.
    
    ##              When cmake is first run in an empty build tree, it ## creates a CMakeCache.txt file and populates it with customizable settings for
    ##              the project.  This option may be used to specify a setting that takes priority over the projectas default value.  The option may
    ##              be repeated for as many cache entries as desired.
    ## 会被存在build目录下的CMakeCache.txt中
    ## -Wno-dev 忽略开发警告
    % cmake -G Ninja ../llvm/ \
      	-DCMAKE_INSTALL_PREFIX=/opt/llvm  \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_FFI=ON \
        -DLLVM_BUILD_LLVM_DYLIB=ON \
        -DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
        -DLLVM_TARGETS_TO_BUILD="host;AMDGPU" \
        -Wno-dev
    
    ## 安装 ninja
    ## Ninja is a small build system with a focus on speed. 
    ## It differs from other build systems in two major respects: it is designed to have its input files generated by a higher-level build system, and it is designed to run builds as fast as possible.
    % brew install ninja
    
    ## -j N     run N jobs in parallel [default=6, derived from CPUs available]
    ## CMake Error at cmake_install.cmake:36 (file):
    ##  file INSTALL cannot set permissions on "/opt/llvm/include/llvm"
    ## 加上sudo
    % sudo ninja -j4 install
    

    替换Clang

    ## 查看系统的Clang的位置
    ~% which clang
    /usr/bin/clang
    
    ~% clang -v 
    Apple LLVM version 10.0.0 (clang-1000.11.45.5)
    Target: x86_64-apple-darwin17.7.0
    Thread model: posix
    InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
    

    根据参考链接7

    新建Xcode工程

    创建用户自定义配置CC,并设置DEBUG时的值为编译完成后Clang二进制的位置。

    ⌘ B 编译,查看编译输出的日志,证明已经使用了编译的Clang

    错误原因:

    Unknown argument: '-index-store-path'
    

    根据参考链接10,在Build Setting 中搜索index并将Enable Index-While-Building Functionality选项设置为NO

    ⌘ B

    错误原因:

    fatal error: error in backend: No available targets are compatible with triple "arm64-apple-ios9.0.0"
    clang-8: error: clang frontend command failed with exit code 70 (use -v to see invocation)
    clang version 8.0.0 (https://git.llvm.org/git/clang.git/ a6eb16ed631365f3bbadd0450ab52746c151794d) (https://git.llvm.org/git/llvm.git/ 1c98a2b870d058132698ae4d67ef954b13dc41b4)
    Target: aarch64-apple-darwin17.7.0
    Thread model: posix
    InstalledDir: /opt/llvm/bin
    

    分析: 因为该手机架构是arm64cmake编译时指定的是 -DLLVM_TARGETS_TO_BUILD="host;AMDGPU",并没有对应的架构

    HowToBuildOnARM

    cmake $LLVM_SRC_DIR -DCMAKE_BUILD_TYPE=Release
    -DLLVM_TARGETS_TO_BUILD=“ARM;X86;AArch64”

    操作

    ## 重新编译
    % cmake -G Ninja ../llvm/ \
      	-DCMAKE_INSTALL_PREFIX=/opt/llvm  \
        -DCMAKE_BUILD_TYPE=Release \
        -DLLVM_ENABLE_FFI=ON \
        -DLLVM_BUILD_LLVM_DYLIB=ON \
        -DCMAKE_EXPORT_COMPILE_COMMANDS=ON \
        -DLLVM_TARGETS_TO_BUILD="host;ARM;X86;AArch64" \
        -Wno-dev
    
    ## 确认
    % grep -r "LLVM_TARGETS_TO_BUILD" CMakeCache.txt
    CMakeCache.txt:LLVM_TARGETS_TO_BUILD:STRING=host;ARM;X86;AArch64
    
    ## 安装 只会处理有变更的部分
    % sudo ninja -j4 install
    

    ⌘ B 成功

    代码

    TryLLVM

    参考

    1. llvm.org
    2. 结构化编译器前端 Clang 介绍
    3. 编译器架构的王者LLVM
    4. cmake.org
    5. wiki-XcodeVersionInfo
    6. 下载标准库libcxx出现svn: E000104: Error running context: Connection reset by peer的解决方案
    7. 安装 LLVM + Clang
    8. 如何让Xcode使用clang的替代版本
    9. Why can’t I create a directory under /opt without sudo
    10. compilation-error-when-using-xcode-9-0-with-clang-cannot-specify-o-when-genera
    展开全文
  • clang static analyzer源码分析(二)

    千次阅读 2016-10-14 09:53:46
    clang static analyzer源码分析(二),主要介绍ExplodedGraph的概念以及对clang static analyzer进行调试
  • 简述 LLVM 与 Clang 及其关系

    万次阅读 多人点赞 2018-07-23 10:55:29
    随着 Android P 的逐步应用,...它们两个都是 C++ 标准库,libc++ 是针对 Clang 编译器特别重写的 C++ 标准库,而 libstdc++ 则是 GCC 的对应 C++ 标准库了。从 Android 市场来说,Android NDK 已在具体应用中放弃...
  • 编译器GCC与Clang的异同

    万次阅读 多人点赞 2018-02-04 13:24:16
    编译器GCC与Clang的异同
  • Clang(v9.0x64).7z

    2020-07-30 23:31:44
    Clang v9.0 VS2017、x64、MT 编译。 无需VS运行库。
  • Clang

    2020-09-30 17:32:55
    Clang 12.0.0 (In-Progress) Release Notes Using Clang as a Compiler Clang Compiler User’s Manual Assembling a Complete Toolchain Clang Language Extensions Clang command line argument reference ...
  • GCC与Clang的异同

    2018-09-19 17:39:33
    GCC:GNU(Gnu's Not Unix)编译器套装(GNU Compiler Collection,GCC),指一套编程语言编译器,以GPL及LGPL许可证所发行的自由软件,也是GNU项目的关键部分,也是GNU工具链的主要组成部分之一。GCC(特别是其中的C语言...
  • clang++编译器使用

    万次阅读 2019-07-15 13:58:08
    编译过程 通常的程序需要经过预处理阶段,编译阶段,汇编阶段,链接阶段 - 预处理阶段:预处理阶段对包含源代码的文本文件(test.cc)处理,比如包含头文件到文件中,替换宏定义。生成预处理后的文件test.i ...
  • 关于Clang的编译使用

    千次阅读 2019-04-04 16:11:05
    文章目录关于Windows下C/C++的编译一、前提(一)预处理(二)编译(三)汇编(四)链接二、使用clang命令(一)包含外部的头文件(二)包含外部的静态库(三)连接静态库1.代码中链接2.编译时命令行链接(四)包含...
  • Ubuntu安装Clang\Clang版本切换

    万次阅读 2019-09-23 16:43:59
    目录1、废话2、安装不同版本的Clang2、Clang不同版本的切换 1、废话 clang这种可以直接用apt-get来安装的,居然还有人写了手动编译的教程。。。直接使用apt-get安装不是更好?虽然说使用apt-get可能不能安装不了...
  • Windows下Clang环境的搭建

    万次阅读 多人点赞 2016-10-14 23:06:26
    Clang简介Clang是一个C语言、C++、Objective-C、C++语言的轻量级编译器。 相对于GCC优点是编译速度更快、编译产出更小、出错提示更友好。 尤其是在比较极端的情况下。个人环境介绍个人是WIN10_X64环境 在安装...
  • 深入研究Clang(一)Clang和LLVM的关系及整体架构

    万次阅读 多人点赞 2013-12-31 15:53:20
    Clang是LLVM框架中的重要前端,深入理解Clang,首先要搞清楚的是它和LLVM的关系,之后要搞清楚的是它的架构。只有这两个问题搞清楚了,才可以真正的深入下去。
  • 1.安装clang command  第一步:首先打开VScode编辑器  第二步:点击左侧“应用商店”栏  第三步:在“应用商店搜索拓展”栏输入关键字“clang”  第四步:安装提示的“C/c++ clang command”插件 2. 安装...
  • Xcode报错clang错误 的解决办法

    千次阅读 2018-09-20 09:51:28
    一般情况下报这个错误,是因为更改了目录结构,肯定是把一些文件夹的位置给更改了,那个改回去就会正常了。 具体为什么更改路径之后就会报错,不得而知,日后再来更新...
  • 在Windows上使用clang编译器

    万次阅读 2017-04-01 13:42:26
    在Stackoverflow等网站上,经常出现各种编译器的对比的结果,其中clang是很常见的,那么,怎样在Windows上使用clang呢,没那么直观。 直接去llvm官网上下载clang的发行包,解压,到bin下面,看到应该是我们想要的...
  • gcc 与 clang 对比

    万次阅读 2018-04-17 19:15:35
    最近写代码的时候, ...于是乎上网搜索发现 有一款编译器 clang, 据说十分好用 就yum安装试了试 等我用它编译代码的时候, 便有一种相见恨晚的感觉 安装 yum list | grep clang yum -y install clang* ...
  • 一、VScode中安装clang 插件 1、首先打开VScode编辑器  2、点击左侧“应用商店”栏,输入关键字“clang”  3、安装提示的“C/c++ clang command adapter”插件 二、下载安装clang 访问提示的网址:...
1 2 3 4 5 ... 20
收藏数 33,692
精华内容 13,476
关键字:

clang