關於clang, scan-build, 和clang test

寫這篇記錄，是由於在用clang分析幾個C/C++開源項目時，我豬腦子同樣地搞不清楚爲何一個待分析的文件，好比：test.c，既然能夠用相似這樣的命令」 clang -cc1 -analyze -analyzer-checker=osx.KeychainAPI test.c 」來分析，爲何還要用scan-build呢？那麼用python和GnuWin32測試和分析器分析之間又有什麼關係呢？測試是在測什麼呢？

 1.clang分析和scan-build分析區別

咱們知道clang是一個C/C++/Object C等編譯器前端，生成中間文件，其中clang static analyzer是clang重要的一部分。當咱們在命令行 clang --analyze就能夠運行靜態分析器。

 scan-build is a command line utility that enables a user to run the static analyzer over their codebase as part of performing a regular build (from the command line).

讓咱們用心理解下上面這段話：scan-build是一個命令行實用程序，它使用戶可以運行靜態分析器，做用於什麼呢？Over codebase，因此codebase（代碼庫）這個分析對象很重要，後面是說，做爲執行正常生成的一部分。

 During a project build, as source files are compiled they are also analyzed in tandem by the static analyzer.Upon completion of the build, results are then presented to the user within a web browser.

在一個項目生成過程當中，當源碼文件被編譯時，它們也被靜態分析器一個接一個地分析。生成完成，結果就會由Web瀏覽器呈現給用戶。

 如今終於知道了，用clang -cc1 -analyze test.c, 這樣的命令只能分析一個單獨的文件，若是要分析一個project，文件之間有組織和結構，也就是咱們上面說到的codebase，就須要用scan-build來分析了。

 2.clang命令使用和scan-build使用

下面簡單羅列一下關於clang 和 scan-build在命令行下怎麼用？

cmd
clang -help
OVERVIEW: clang LLVM compiler
USAGE: clang.exe [options] <inputs>

OPTIONS:
--analyze               Run the static analyzer
-c                      Only run preprocess, compile, and assemble steps
-E                      Only run the preprocessor
-g                      Generate source-level debug information
-help                   Display available options
-o <file>               Write output to <file>

-Xanalyzer <arg>        Pass <arg> to the static analyzer

-Xclang <arg>           Pass <arg> to the clang compiler

經常使用命令行：

clang -help
clang -cc1 -analyzer-checker-help
clang --analyze -Xclang -analyzer-checker=alpha.core.FixedAddr test.c
clang --analyze -Xanalyzer -analyzer-checker=alpha.unix.SimpleStream dblclose.c

A complete list of options can be obtained by running scan-build with no arguments or scan-build -h.

cmd
scan-build / scan-build -h
USAGE: scan-build [options] <build command> [build options]
 
<build command>
scan-build make
scan-build xcodebuild
In the first case scan-build analyzes the code of a project built with make and in the second case scan-build analyzes a project built using xcodebuild.
[build options]：for example -j4
OPTIONS:
generally ,we don't use any options.
-o
-h/
-V
--use-analyzer

經常使用命令：

首先指向待分析項目的目錄下：
Myproject >> scan-build --use-analyzer=D:\LLVM\build\Debug\bin\clang.exe make

針對上面這一行命令，我想多說一些，由於感受確實涉及到不少沒有接觸過的內容。我從接觸計算機甚至編程以來，都是使用Windows，因此對Linux幾乎一無所知，只知道是另外一種操做系統。忽然，最近有這樣一些字母頻繁地出現，就不得不稍微地瞭解一點東西了。好比：GNU，GnuWin32，WinGW，Makefile這就都是什麼鬼。

安裝了GnuWin32，就可讓Windows命令行知道」make」是什麼意思，一些習慣於在Linux上開發的人員，該在windows下開發時，須要一套相似Linux的命令行工具，因而GnuWin32應運而生。

當未安裝WinGW時，執行上面的命令，你會一直被提示，gcc找不到，這是由於scan-build的工做原理是這樣的：scan-build has little or no knowledge about how you build your code. It works by overriding the CC and CXX environment variables to (hopefully) change your build to use a "fake" compiler instead of the one that would normally build your project. This fake compiler executes either clang or gcc (depending on the platform) to compile your code and then executes the static analyzer to analyze your code.

因此能夠看到，scan-build須要用到gcc/clang做爲編譯器，而咱們沒有安裝gcc，因此才被提示。WinGW是什麼呢？和GCC有什麼關係呢？Minimalist GNU for Windows，又稱mingw32，是將GCC編譯器和GNU Binutils移植到Win32平臺下的產物，包括一系列頭文件（Win32API）、庫和可執行文件。

咱們按照教程安裝好以後，終於能夠正常分析一個開源軟件了，真是開心，然而事情並非想象的這樣。

Makefile找不到，這又是什麼？makefile其實就是make這個命令所要執行的對象，咱們知道Linux下的make至關於Windows VS下的build，但是我總得知道怎麼生成，才能生成啊，好比我得知道編譯main.c以前先要編譯的頭文件之類的，這些要有一個文件告訴make。這個文件就是makefile。這裏有一篇極好的文章推薦給你們，說得特別清晰。http://blog.csdn.net/liang13664759/article/details/1771246

 到這裏總算了解scan-build了，對於一些待分析開源軟件沒有makefile的現象，只能參考上面的文章，本身寫一個makefile了。

 3.clang-test

首先咱們簡單說一下clang-test與clang -analyzer有什麼聯繫和區別。由於總感受都是在測試檢測什麼的啊，我大概真是有病，說實話，真是沒啥聯繫。Clang雖然是用來檢測別人代碼的缺陷的，因此它用clang -analyze和scan-build檢測輸入的工程或源碼的缺陷，但實際上它自己本身也是一個工程，一個工程若是作了二次開發，固然須要作單元測試什麼的，因此纔會說」Every patch should be well tested with Clang regression tests」,每一次修改（補丁）都須要作clang迴歸測試。怎麼作呢？

來官網瞅兩眼（http://clang.llvm.org/get_started.html#build），咱們記得在學習配置時，最後有提到關於測試的事情。首先在測試前，必定要確保咱們安裝了Python和GnuWin32，關於GnuWin32，你要肯定一下你安裝的是getGunWin 32仍是GunWin 32，真是人生到處都是陷阱！[捂臉]

http://clang.llvm.org/hacking.html#testingWindows 咱們很是高興找到了方法，官方文檔值得信賴啊，而後咱們來看個神坑：

--param=build_mode=Win32 --param=build_config=Debug

生成模式:Win32; 生成配置: Debug     彷佛沒什麼錯，咱們看到VS上顯示的就是Debug和Win32

但是，若是咱們按照上面的方式作，命令行會返回找不到一堆東西，因而咱們就奇怪了，由於按照命令行提示，咱們在指定路徑下也找不到對應的文件，這也不能怪電腦啊，個人天。哈哈，不過不要緊，又發現一個連接：

咱們來看下：http://llvm.org/docs/GettingStartedVS.html

 --param build_config=Win32  --param build_mode=Debug

生成模式:Debug; 生成配置: Win32

請告訴我，發生了什麼，個人哥，怎麼還不同啊，因而咱們把上面的換一下，啊，問題居然解決了，因此，綜上，咱們應該在測試時用的是相似下面的例子：

python D:\LLVM\llvm\utils\lit\lit.py -sv --param build_config=Win32 --param build_mode=Debug --param=clang_site_config=D:\LLVM\build\tools\clang\test\lit.site.cfg D:\LLVM\llvm\tools\clang\test\Sema

總要找下緣由的，咱們找到D:\LLVM\build\test\Unit下的配置文件lit.site.cfg，看下里面的內容，咱們就大體明白了。

 

補充說明:

在安裝完成MinGW以後，使用scan-build時可能會出現沒法定位程序輸入點  動態連接庫xxx.dll...具體我也記不清楚了，這個錯誤多是由於在添加環境變量Path時，gcc的位置位於某個也含有這個動態庫的軟件或應用的後面，系統找的時候，先找到了path裏前面的應用程序的路徑中的這個動態庫，而沒有繼續去找gcc中的，因此引發錯誤，解決辦法是把gcc的bin目錄放path中相對前面一點的位置，放在你認爲可能含有這個.dll的目錄前面。。。。

參考文獻

http://clang-analyzer.llvm.org/scan-build.html

http://clang-analyzer.llvm.org/checker_dev_manual.html

http://xinsuiyuer.github.io/blog/2014/01/12/clang-static-analyzer/

http://blog.csdn.net/liang13664759/article/details/1771246