ccc
v2.1
用於解析 PS2 遊戲偵錯符號的函式庫和命令列工具集。 1.x 系列版本專注於 .mdebug 部分中的 STABS 符號，而 2.x 系列版本還可以解析標準 ELF 符號和 SNDLL 連結器符號。 DWARF 支援正在進行中。
C++ 符號分解器，支援新的 Itanium C++ ABI (GCC 3+) 修飾方案和舊的 GCC 2 方案。
半工作的 EE 核心 MIPS 反組譯器。可能不太有趣。
符號表解析器和轉儲器。它可以提取以下資訊：
支援以下輸出格式：
這旨在與 ghidra-emotionengine-reloaded （>= 2.1.0 或不穩定版本之一）一起使用，以將所有這些資訊匯入 Ghidra。請注意，儘管名稱如此，但 STABS 分析器應該適用於 R3000 (IOP)，也可能適用於其他 MIPS 處理器。
這與 stdump 類似，只不過它將輸出組織到單獨的原始檔案中，並且具有許多額外的功能，旨在嘗試使所述輸出更接近有效的原始程式碼。輸出目錄中必須提供SOURCES.txt文件，該文件可以使用stdump files命令產生（您應該手動修復路徑，以便它們相對於輸出目錄，並刪除地址）。此外，不以// STATUS: NOT STARTED開頭的非空檔案不會被覆蓋。
如果輸出目錄中提供了FUNCTIONS.txt檔案（可以使用 Ghidra 隨附的CCCDecompileAllFunctions.java腳本產生），則該檔案中的程式碼將用於填入輸出中的函式體。在這種情況下，發出的第一組局部變數宣告將從符號中恢復，第二組將從函數檔案中提供的程式碼中恢復。函數名稱被分解。
全域變數資料將根據其資料類型以結構化方式列印。
資料類型將被分類到其相應的文件中。由於此資訊未儲存在符號表中，因此 uncc 使用啟發式方法將類型對應到檔案。當類型僅出現在一個翻譯單元中時，類型將被放入.c或.cpp檔案中；當存在多個翻譯單元時，類型將被放入.h檔案中（因此必須使用啟發式方法來確定將它們放在何處時）。
建議在輸出中使用程式碼格式化程序，例如clang-format或astyle 。
cmake -B bin/
cmake --build bin/
mdebugread.c （讀取）ecoff.c （寫作）include/coff/sym.h （標頭）stabs.c （讀）stabsread.c （讀取）dbxread.c （讀取）dbxout.c （編寫）stab.def來自 gcc（符號代碼） CCC 程式庫和相關命令列工具的原始程式碼是根據 MIT 許可證發布的。
使用 GNU demangler，其中包含根據 GPL 和 LGPL 許可的來源檔案。 RapidJSON 在 MIT 許可下使用。測試套件在 3-Clause BSD 授權下使用 GoogleTest 函式庫。
