在使用 STATIC 代碼靜態(tài)驗證工具（后文簡略為'STATIC'） 的過程中，客戶最常遇到的困難之一就是工具鏈的設置問題。工具鏈設置之所以困難，是因為不清楚為什么需要輸入各種設定項，而且一旦出錯，很難排查和解決。

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

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

預處理階段（Preprocessing）

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

<圖1> 預處理階段

編譯階段（Compiling）

在經(jīng)過預處理之后，編譯器會以預處理后的代碼為基礎，正式開始編譯工作。這一過程可以大致分為以下四個階段：

1. 詞法分析（Lexical Analysis）

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

2. 語法分析（Syntax Analysis）

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

3. 語義分析（Semantic Analysis）

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

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

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

<圖2> 編譯階段

鏈接階段（linking）

在完成編譯階段后，每個源文件會生成一個名為目標文件（Object File）的文件。但這些目標文件還不是最終的可執(zhí)行文件，因為其中涉及到的外部函數(shù)或全局變量等信息的地址尚未確定，仍需進一步處理。鏈接階段（linking）就是將這些目標文件與所需的庫文件連接起來，生成操作系統(tǒng)可以執(zhí)行的完整的可執(zhí)行文件（Binary）的過程。鏈接過程主要包括以下三個步驟：

1. 符號解析與地址確定

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

2. 庫文件合并

將程序中使用的標準庫或用戶自定義庫與目標文件進行合并。對于需要外部引用的函數(shù)或類，從庫中提取相應的實現(xiàn)并進行鏈接。像 printf()、std::vector 這樣的標準函數(shù)也是在這個階段被鏈接進來的。

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

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

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

STATIC之所以需要了解這些構(gòu)建過程，是因為它在進行靜態(tài)分析時會模擬整個構(gòu)建流程。因為，只有準確知道用戶使用了哪種編譯器和設置了哪些選項，才能進行精確的靜態(tài)分析。因此，工具鏈設置不僅僅是簡單的參數(shù)輸入，更是提升STATIC分析準確性和可信度的必要步驟。

<圖3> 鏈接階段

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

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

· 收集分析所需的信息

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

· 驗證收集到的信息

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

· 上傳至服務器

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

<圖4> 工具鏈設置提取流程

收集分析所需的信息

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

· SPEC 模式

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

· Build Hook 模式

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

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

<圖5> Hooking流程

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

· Built-in 方式

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

· Original 方式

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

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

驗證

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

上傳服務器

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

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

Build Hook 模式

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

<圖6> Build Hook模式畫面

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

<圖7> Configuration 過程

SPEC 模式

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

<圖8> Build Hooking 開關關閉后添加文件的流程

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

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

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

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