在使用 STATIC 代碼靜態(tài)驗(yàn)證工具（后文簡(jiǎn)略為'STATIC'） 的過(guò)程中，客戶(hù)最常遇到的困難之一就是工具鏈的設(shè)置問(wèn)題。工具鏈設(shè)置之所以困難，是因?yàn)椴磺宄槭裁葱枰斎敫鞣N設(shè)定項(xiàng)，而且一旦出錯(cuò)，很難排查和解決。

為了幫助那些對(duì)工具鏈設(shè)置不熟悉的用戶(hù)，本篇文章將為您簡(jiǎn)單易懂地整理出以下內(nèi)容：為什么需要進(jìn)行工具鏈設(shè)置、STATIC是如何提取工具鏈信息的，以及一個(gè)簡(jiǎn)單的設(shè)置流程示例。

要理解為什么需要進(jìn)行工具鏈設(shè)置，首先需要了解C/C++代碼是如何被轉(zhuǎn)換為可執(zhí)行文件的。C/C++源代碼會(huì)經(jīng)過(guò)以下三個(gè)主要步驟，最終生成操作系統(tǒng)可以執(zhí)行的程序：

預(yù)處理階段（Preprocessing）

在進(jìn)行C/C++開(kāi)發(fā)時(shí)，為了減少重復(fù)代碼的使用并提高可讀性，通常會(huì)使用宏和頭文件。預(yù)處理階段的作用就是展開(kāi)定義的宏，并將分散的頭文件整合成一個(gè)源代碼文件，從而生成一個(gè)“翻譯單元”（Translation Unit）。

<圖1> 預(yù)處理階段

編譯階段（Compiling）

在經(jīng)過(guò)預(yù)處理之后，編譯器會(huì)以預(yù)處理后的代碼為基礎(chǔ)，正式開(kāi)始編譯工作。這一過(guò)程可以大致分為以下四個(gè)階段：

1. 詞法分析（Lexical Analysis）

讀取源代碼并將其拆分為構(gòu)成程序的最小單元（即“詞法單元”，Token）。 例如，變量名、關(guān)鍵字、運(yùn)算符等都會(huì)被識(shí)別為各自的標(biāo)記。

2. 語(yǔ)法分析（Syntax Analysis）

對(duì)詞法分析得到的標(biāo)記進(jìn)行語(yǔ)法檢查，確認(rèn)它們是否符合語(yǔ)言的語(yǔ)法規(guī)則。 在此階段會(huì)生成“抽象語(yǔ)法樹(shù)”（AST，Abstract Syntax Tree）。 AST是一種以樹(shù)狀結(jié)構(gòu)層次化地表示程序結(jié)構(gòu)的方式，是后續(xù)分析與優(yōu)化的基礎(chǔ)。

3. 語(yǔ)義分析（Semantic Analysis）

在生成的AST基礎(chǔ)上，進(jìn)一步理解程序的實(shí)際含義。 不僅檢查語(yǔ)法是否正確，還會(huì)識(shí)別語(yǔ)義錯(cuò)誤（Semantic Error），比如將整數(shù)與字符串相加、除零等不合邏輯或錯(cuò)誤的運(yùn)算。

4. 中間代碼生成（Intermediate Code Generation）

在完成語(yǔ)法和語(yǔ)義分析之后，基于AST生成中間代碼，作為轉(zhuǎn)換為機(jī)器碼前的中間步驟。 中間代碼通常是與平臺(tái)無(wú)關(guān)的形式，之后會(huì)用于最終代碼的生成和優(yōu)化過(guò)程。

<圖2> 編譯階段

鏈接階段（linking）

在完成編譯階段后，每個(gè)源文件會(huì)生成一個(gè)名為目標(biāo)文件（Object File）的文件。但這些目標(biāo)文件還不是最終的可執(zhí)行文件，因?yàn)槠渲猩婕暗降耐獠亢瘮?shù)或全局變量等信息的地址尚未確定，仍需進(jìn)一步處理。鏈接階段（linking）就是將這些目標(biāo)文件與所需的庫(kù)文件連接起來(lái)，生成操作系統(tǒng)可以執(zhí)行的完整的可執(zhí)行文件（Binary）的過(guò)程。鏈接過(guò)程主要包括以下三個(gè)步驟：

1. 符號(hào)解析與地址確定

識(shí)別各個(gè)目標(biāo)文件中散布的函數(shù)和全局變量等“符號(hào)（Symbol）”，并為它們分配內(nèi)存地址，使它們相互連接。這一過(guò)程的關(guān)鍵是找到在其他文件中定義的函數(shù)或變量，并將其正確連接起來(lái)。

2. 庫(kù)文件合并

將程序中使用的標(biāo)準(zhǔn)庫(kù)或用戶(hù)自定義庫(kù)與目標(biāo)文件進(jìn)行合并。對(duì)于需要外部引用的函數(shù)或類(lèi)，從庫(kù)中提取相應(yīng)的實(shí)現(xiàn)并進(jìn)行鏈接。像 printf()、std::vector 這樣的標(biāo)準(zhǔn)函數(shù)也是在這個(gè)階段被鏈接進(jìn)來(lái)的。

3. 生成可執(zhí)行文件

當(dāng)所有符號(hào)都已正確鏈接、內(nèi)存地址也全部確認(rèn)后，就會(huì)生成一個(gè)操作系統(tǒng)能夠識(shí)別和執(zhí)行的二進(jìn)制可執(zhí)行文件。

正如所見(jiàn)，從C/C++源代碼生成最終可執(zhí)行文件的過(guò)程中，會(huì)經(jīng)歷預(yù)處理、編譯、鏈接等多個(gè)階段，而每個(gè)階段中編譯器的設(shè)置和環(huán)境都會(huì)產(chǎn)生重要影響。

STATIC之所以需要了解這些構(gòu)建過(guò)程，是因?yàn)樗谶M(jìn)行靜態(tài)分析時(shí)會(huì)模擬整個(gè)構(gòu)建流程。因?yàn)椋挥袦?zhǔn)確知道用戶(hù)使用了哪種編譯器和設(shè)置了哪些選項(xiàng)，才能進(jìn)行精確的靜態(tài)分析。因此，工具鏈設(shè)置不僅僅是簡(jiǎn)單的參數(shù)輸入，更是提升STATIC分析準(zhǔn)確性和可信度的必要步驟。

<圖3> 鏈接階段

為了讓STATIC能夠?qū)υ创a進(jìn)行準(zhǔn)確的分析，必須完整反映出用戶(hù)實(shí)際使用的編譯環(huán)境信息。 為此，STATIC使用了其自主開(kāi)發(fā)的工具 CSBUILD，來(lái)自動(dòng)提取并整理用戶(hù)的工具鏈設(shè)置信息。

CSBUILD 主要執(zhí)行以下三個(gè)核心任務(wù)

· 收集分析所需的信息

CSBUILD會(huì)全面收集進(jìn)行代碼編譯所需的各種信息，不僅包括源代碼文件列表，還包括所使用的編譯器類(lèi)型與版本、編譯時(shí)的選項(xiàng)、宏定義、系統(tǒng)頭文件與用戶(hù)自定義頭文件路徑等。通過(guò)這些信息，STATIC可以在盡可能接近用戶(hù)真實(shí)開(kāi)發(fā)環(huán)境的條件下讀取和分析代碼。

· 驗(yàn)證收集到的信息

CSBUILD會(huì)測(cè)試所收集的信息是否能夠成功編譯，以提前發(fā)現(xiàn)是否存在缺失的文件或路徑配置錯(cuò)誤等問(wèn)題。由于STATIC的分析是基于 AST（抽象語(yǔ)法樹(shù)）進(jìn)行的，一旦發(fā)生編譯錯(cuò)誤，將難以進(jìn)行準(zhǔn)確的分析。因此，通過(guò)驗(yàn)證步驟可以最大限度地減少錯(cuò)誤，并在必要時(shí)引導(dǎo)用戶(hù)進(jìn)行修復(fù)。

· 上傳至服務(wù)器

通過(guò)驗(yàn)證的信息會(huì)被轉(zhuǎn)換成STATIC分析服務(wù)器能夠識(shí)別的標(biāo)準(zhǔn)格式，并進(jìn)行壓縮上傳。服務(wù)器由此可以準(zhǔn)確還原用戶(hù)的實(shí)際開(kāi)發(fā)環(huán)境，從而提供更加可靠和高質(zhì)量的分析結(jié)果。STATIC的目標(biāo)不僅是分析源代碼本身，更是要理解代碼所處的開(kāi)發(fā)環(huán)境和配置。CSBUILD正是為了自動(dòng)化這一過(guò)程而開(kāi)發(fā)的工具，它有效降低了繁瑣的工具鏈設(shè)置負(fù)擔(dān)，讓任何人都能更輕松地使用靜態(tài)分析工具。

<圖4> 工具鏈設(shè)置提取流程

收集分析所需的信息

為考慮到用戶(hù)所處的各種開(kāi)發(fā)環(huán)境，STATIC提供了兩種方式，幫助用戶(hù)便捷地收集進(jìn)行分析所需的信息：

· SPEC 模式

SPEC模式是指用戶(hù)手動(dòng)編寫(xiě)JSON格式的文件，在其中輸入分析所需的源代碼列表、編譯器信息、編譯選項(xiàng)等。 雖然這種方式略顯繁瑣，但如果用戶(hù)希望自由配置或精細(xì)調(diào)整構(gòu)建環(huán)境，SPEC模式就是一個(gè)非常有用的選擇。

· Build Hook 模式

Build Hook模式是在用戶(hù)實(shí)際構(gòu)建項(xiàng)目的過(guò)程中，自動(dòng)收集分析所需信息的一種方式。 這一模式的關(guān)鍵技術(shù)就是Hooking。Hooking是將開(kāi)發(fā)者編寫(xiě)的 Hook庫(kù)插入到構(gòu)建過(guò)程中，攔截API調(diào)用、消息傳遞或事件流程等信息的技術(shù)。

正如前文所述，STATIC的工作原理與編譯器非常相似，因此在構(gòu)建過(guò)程中通過(guò)Hooking獲取的所有信息，幾乎可以涵蓋進(jìn)行靜態(tài)分析所需的全部配置。 借助 Hooking技術(shù)，STATIC能夠自然且全面地提取分析配置，無(wú)需用戶(hù)額外操作，提升了分析的準(zhǔn)確性與便捷性。

<圖5> Hooking流程

此外，用戶(hù)還可以選擇不同的方式來(lái)收集源代碼中所使用的頭文件。

· Built-in 方式

該方式使用STATIC內(nèi)置的預(yù)處理解析器（Parser）對(duì)源代碼進(jìn)行直接分析，從中提取出所需的頭文件。  適用于不依賴(lài)實(shí)際構(gòu)建過(guò)程、希望快速分析源代碼的場(chǎng)景。

· Original 方式

該方式是在用戶(hù)實(shí)際的構(gòu)建環(huán)境中執(zhí)行構(gòu)建任務(wù)，并在過(guò)程中原樣提取出實(shí)際使用到的頭文件。  這種方式可以最大限度地還原真實(shí)環(huán)境，確保分析結(jié)果與實(shí)際構(gòu)建一致。

用戶(hù)可根據(jù)項(xiàng)目特性和分析需求，靈活選擇最合適的頭文件收集方法。

驗(yàn)證

在前一階段收集到信息的基礎(chǔ)上，STATIC會(huì)在內(nèi)部驗(yàn)證這些信息是否能夠用于實(shí)際編譯。STATIC分析器并不真正進(jìn)行編譯，而是通過(guò)生成AST（抽象語(yǔ)法樹(shù)）來(lái)執(zhí)行靜態(tài)分析。因此，如果代碼無(wú)法正常編譯，AST 也將無(wú)法正確生成，最終分析也會(huì)失敗。通過(guò)這個(gè)過(guò)程，可以驗(yàn)證所收集的信息是否準(zhǔn)確，提前防止分析錯(cuò)誤的發(fā)生。

上傳服務(wù)器

CSBUILD會(huì)將上述過(guò)程中收集到的源代碼、編譯器信息、編譯選項(xiàng)以及分析配置等內(nèi)容，按照與服務(wù)器約定好的格式進(jìn)行保存，并進(jìn)行壓縮后上傳至服務(wù)器。

前面我們已經(jīng)了解了為什么在C/C++項(xiàng)目中需要進(jìn)行復(fù)雜的工具鏈設(shè)置，以及STATIC是如何在內(nèi)部收集這些信息的。接下來(lái)，我們來(lái)看一下STATIC用戶(hù)在實(shí)際使用過(guò)程中進(jìn)行工具鏈設(shè)置的具體流程。

Build Hook 模式

Build Hook模式是在用戶(hù)的實(shí)際環(huán)境中執(zhí)行構(gòu)建的同時(shí)，自動(dòng)收集分析所需信息的一種方式。首先，在STATIC設(shè)置界面的頂部，啟用Build Hooking開(kāi)關(guān)。使用此模式時(shí)，需要輸入構(gòu)建命令和編譯器的安裝路徑。

<圖6> Build Hook模式畫(huà)面

選擇用于構(gòu)建項(xiàng)目的編譯器，并添加所使用的系統(tǒng)頭文件路徑。 如果有需要額外添加或排除的編譯選項(xiàng)，可以分別填寫(xiě)在 "Configuration to add" 和 "Configuration to exclude" 中。其中的preprocessor條目是用于選擇之前提到的頭文件收集方式，可選擇Original或Built-in模式。

<圖7> Configuration 過(guò)程

SPEC 模式

SPEC模式是用戶(hù)手動(dòng)輸入要分析的文件及環(huán)境配置信息的方式。首先，在STATIC設(shè)置界面頂部，將Build Hooking開(kāi)關(guān)關(guān)閉。 然后，手動(dòng)添加需要進(jìn)行分析的源文件。

<圖8> Build Hooking 開(kāi)關(guān)關(guān)閉后添加文件的流程

接下來(lái)，輸入所使用的編譯器信息和頭文件路徑。 在這個(gè)過(guò)程中，與Build Hook模式不同，無(wú)需單獨(dú)選擇頭文件收集方式。由于SPEC模式并不會(huì)在用戶(hù)環(huán)境中實(shí)際執(zhí)行構(gòu)建，因此默認(rèn)使用STATIC內(nèi)置的解析器（Built-in Parser） 來(lái)收集頭文件。 換句話說(shuō)，分析環(huán)境完全依賴(lài)于用戶(hù)所輸入的信息來(lái)構(gòu)建。

<圖9> 編譯信息，頭文件路徑輸入流程

STATIC通過(guò)靜態(tài)分析，在bug實(shí)際發(fā)生之前就提前發(fā)現(xiàn)潛在問(wèn)題，幫助開(kāi)發(fā)者節(jié)省大量時(shí)間與成本，并顯著提升代碼質(zhì)量。

此外，STATIC還提供了多種編碼風(fēng)格規(guī)范檢查規(guī)則，即使不是bug，也能幫助找出可優(yōu)化的代碼，進(jìn)一步改善代碼結(jié)構(gòu)。尤其是在 C/C++這類(lèi)開(kāi)發(fā)環(huán)境多樣且復(fù)雜的語(yǔ)言中，工具鏈配置常常令人望而卻步。STATIC致力于簡(jiǎn)化和自動(dòng)化這一流程，讓任何人都能輕松開(kāi)展靜態(tài)代碼分析工作。