A. 如何使用Ninja快速編譯LLVM和Clang
1，Build llvm/clang/lldb/lld 3.5.0等組件
1.0 准備：
至少需要從llvm.org下載llvm, cfe, lldb, compiler-rt,lld等3.5.0版本的代碼。
$tar xf llvm-3.5.0.src.tar.gz
$cd llvm-3.5.0.src
$mkdir -p tools/clang
$mkdir -p tools/clang/tools/extra
$mkdir -p tools/lld
$mkdir -p projects/compiler-rt
$tar xf cfe-3.5.0.src.tar.xz -C tools/clang --strip-components=1
$tar xf compiler-rt-3.5.0.src.tar.xz -C projects/compiler-rt --strip-components=1
$tar xf lldb-3.5.0.src.tar.xz -C tools/clang/tools/extra --strip-components=1
$tar xf lld-3.5.0.src.tar.xz -C tools/lld --strip-components=1
1.1 【可選】使用clang --stdlib=libc++時，自動添加-lc++abi。
libc++組件可以使用gcc libstdc++的supc++ ABI，也可以使用c++abi，cxxrt等，實際上自動添加-lc++abi是不必要的，這里這么處理，主要是為了方便起見。實際上完全可以在「clang++ -stdlib=libc++」時再手工添加-lc++abi給鏈接器。
這里涉及到鏈接時DSO隱式還是顯式的問題，早些時候ld在鏈接庫時會自動引入由庫引入的依賴動態庫，後來因為這個行為的不可控性，所以ld鏈接器的行為做了修改，需要顯式的寫明所有需要鏈接的動態庫，才會有手工添加-lc++abi這種情況出現。
--- llvm-3.0.src/tools/clang/lib/Driver/ToolChain.cpp 2012-03-26 18:49:06.663029075 +0800
+++ llvm-3.0.srcn/tools/clang/lib/Driver/ToolChain.cpp 2012-03-26 19:36:04.260071355 +0800
@@ -251,6 +251,7 @@
switch (Type) {
case ToolChain::CST_Libcxx:
CmdArgs.push_back("-lc++");
+ CmdArgs.push_back("-lc++abi");
break;
case ToolChain::CST_Libstdcxx:
1.2 【必要】給clang++添加-fnolibgcc開關。
這個開關主要用來控制是否連接到libgcc或者libunwind。
註：libgcc不等於libunwind。libgcc_eh以及supc++的一部分跟libunwind功能相當。
註：libgcc_s和compiler_rt的一部分相當。
這個補丁是必要的， 不會對clang的正常使用造成任何影響 ，只有在使用「-fnolibgcc"參數時才會起作用。
之所以進行了很多unwind的引入，主要是為了避免不必要的符號缺失麻煩，這里的處理相對來說是干凈的，通過as-needed規避了不必要的引入。
--- llvm-static-3.5.0.bak/tools/clang/lib/Driver/Tools.cpp 2014-09-10 13:46:02.581543888 +0800
+++ llvm-static-3.5.0/tools/clang/lib/Driver/Tools.cpp 2014-09-10 16:03:37.559019321 +0800
@@ -2060,9 +2060,15 @@
".a");
CmdArgs.push_back(Args.MakeArgString(LibClangRT));
- CmdArgs.push_back("-lgcc_s");
- if (TC.getDriver().CCCIsCXX())
- CmdArgs.push_back("-lgcc_eh");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else {
+ CmdArgs.push_back("-lgcc_s");
+ if (TC.getDriver().CCCIsCXX())
+ CmdArgs.push_back("-lgcc_eh");
+ }
}
static void addProfileRT(
@@ -7150,24 +7156,50 @@
bool isAndroid = Triple.getEnvironment() == llvm::Triple::Android;
bool StaticLibgcc = Args.hasArg(options::OPT_static_libgcc) ||
Args.hasArg(options::OPT_static);
+
+
+
if (!D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
if (StaticLibgcc || isAndroid) {
if (D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
} else {
if (!D.CCCIsCXX())
CmdArgs.push_back("--as-needed");
- CmdArgs.push_back("-lgcc_s");
+ if (Args.hasArg(options::OPT_fnolibgcc))
+ CmdArgs.push_back("-lunwind");
+ else
+ CmdArgs.push_back("-lgcc_s");
if (!D.CCCIsCXX())
CmdArgs.push_back("--no-as-needed");
}
if (StaticLibgcc && !isAndroid)
- CmdArgs.push_back("-lgcc_eh");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc_eh");
else if (!Args.hasArg(options::OPT_shared) && D.CCCIsCXX())
- CmdArgs.push_back("-lgcc");
+ if (Args.hasArg(options::OPT_fnolibgcc)) {
+ CmdArgs.push_back("--as-needed");
+ CmdArgs.push_back("-lunwind");
+ CmdArgs.push_back("--no-as-needed");
+ } else
+ CmdArgs.push_back("-lgcc");
// According to Android ABI, we have to link with libdl if we are
// linking with non-static libgcc.
--- llvm-static-3.5.0.bak/tools/clang/include/clang/Driver/Options.td 2014-08-07 12:51:51.000000000 +0800
+++ llvm-static-3.5.0/tools/clang/include/clang/Driver/Options.td 2014-09-10 13:36:34.598511176 +0800
@@ -788,6 +788,7 @@
def fomit_frame_pointer : Flag<["-"], "fomit-frame-pointer">, Group<f_Group>;
def fopenmp : Flag<["-"], "fopenmp">, Group<f_Group>, Flags<[CC1Option, NoArgumentUnused]>;
def fopenmp_EQ : Joined<["-"], "fopenmp=">, Group<f_Group>, Flags<[CC1Option]>;
+def fnolibgcc : Flag<["-"], "fnolibgcc">, Group<f_Group>, Flags<[CC1Option, NoArgumentUnused]>;
def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, Group<f_Group>;
def foptimize_sibling_calls : Flag<["-"], "foptimize-sibling-calls">, Group<f_Group>;
def force__cpusubtype__ALL : Flag<["-"], "force_cpusubtype_ALL">;
1.3 llvm的其他補丁。
llvm/clang將gcc toolchain的路徑hard code在代碼中，請查閱tools/clang/lib/Driver/ToolChains.cpp。
找到x86_64-redhat-linux之類的字元串。
如果沒有你系統特有的gcc tripple string，請自行添加。
這個tripple string主要是給llvm/clang搜索gcc頭文件等使用的，不影響本文要構建的toolchain
1.4 構建clang/llvm/lldb
本文使用ninja。順便說一下，llvm支持configure和cmake兩種構建方式。可能是因為工程太大，這兩種構建方式的工程文件都有各種缺陷（主要表現在開關選項上，比如configure有，但是cmake卻沒有等）。llvm-3.4.1就是因為cmake工程文件的錯誤而導致了3.4.2版本的發布。
綜合而言，cmake+ninja的方式是目前最快的構建方式之一，可以將構建時間縮短一半以上。
mkdir build
cd build
cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_BUILD_TYPE="Release" \
-DCMAKE_CXX_FLAGS="-std=c++11" \
-DBUILD_SHARED_LIBS=OFF \
-DLLVM_ENABLE_PIC=ON \
-DLLVM_TARGETS_TO_BUILD="all" \
-DCLANG_VENDOR="MyOS" ..
ninja
ninja install
如果系統原來就有clang/clang++的可用版本，可以添加：
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
這樣就會使用系統的clang++來構建llvm/clang
2，測試clang/clang++。
自己找幾個簡單的c/cpp/objc等編譯測試一下即可。完整測試可以在構建時作ninja check-all
3，libunwind/libc++/libc++abi，一套不依賴libgcc, libstdc++的c++運行庫。
3.1 從https://github.com/pathscale/libunwind 獲取代碼。
libunwind有很多個實現，比如gnu的libunwind, path64的libunwind，還有libcxxabi自帶的Unwinder.
這里作下說明：
1)，gnu的libunwind會有符號缺失和沖突。
2)，libcxxabi自帶的Unwinder是給mac和ios用的，也就是只能在darwin體系構建。目前Linux的實現仍然不全，等linux實現完整了或許就不再需要path64的unwind實現了。
暫時建議使用pathscale的unwind實現。
mkdir -p build
cd build
cmake -G Ninja -DCMAKE_C_COMPILER=clang -DCMAKE_C_FLAGS="-m64" ..
ninja
mkdir -p /usr/lib
cp src/libunwind.so /usr/lib
cp src/libunwind.a /usr/lib
3.2 第一次構建libcxx.
必須先構建一次libcxx，以便後面構建libcxxabi。這里構建的libcxx實際上是使用gcc的libgcc/stdc++/supc++的。
打上這個補丁來禁止libgcc的引入：
diff -Nur libcxx/cmake/config-ix.cmake libcxxn/cmake/config-ix.cmake
--- libcxx/cmake/config-ix.cmake 2014-06-25 06:57:50.000000000 +0800
+++ libcxxn/cmake/config-ix.cmake 2014-06-25 09:05:24.980350544 +0800
@@ -28,5 +28,4 @@
check_library_exists(c printf "" LIBCXX_HAS_C_LIB)
check_library_exists(m ccos "" LIBCXX_HAS_M_LIB)
check_library_exists(rt clock_gettime "" LIBCXX_HAS_RT_LIB)
-check_library_exists(gcc_s __gcc_personality_v0 "" LIBCXX_HAS_GCC_S_LIB)
編譯安裝：
mkdir build
cd build
cmake \
-G Ninja \
-DCMAKE_INSTALL_PREFIX=/usr \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
..
ninja
ninja install
3.3，測試第一次構建的libcxx。
使用"clang++ -stdlib=libc++ -o test test.cpp -lstdc++"編譯簡單c++代碼，檢查是否出錯。(如果前面構建clang是已經apply了c++abi的鏈接補丁，這里會出現找不到c++abi的情況，跳過即可)
使用"ldd test"查看test二進制動態庫使用情況。可以發現，test依賴於libgcc_s/libc++/libstdc++。（多少有些不爽了吧？使用了libc++居然還要依賴libstdc++？）
B. windows 7 x64用cmake,mingw32安裝LLVM，編譯時報錯MemoryBuffer.cpp:381:25: error
Microsoft Visual Studio--common--MSDev98--Bin—MSDEV.EXE,通過此路徑找到MSDEV.EXE可執行文件（或者右擊桌面VC圖標，選擇打開文件位置）。
右鍵--屬性--常規，將MSDEV.EXE更名為MSDEV1.EXE(其它名稱也行，如MSDEV2.EXE).
右鍵--屬性--兼容性，兼容模式選擇Windows XP(service pack2)"或者WindowsXP(service pack3).許可權等級勾選為「以管理員身份運行此程序」，點擊確定。
重新運行VC6.0，應該可以完美運行（如果第一次報錯，那麼關閉，重新打開應該就可以了）。
C. 目前主流的C語言編譯軟體是什麼
C語言相比其他很多新興的、復雜的語言，語法還是簡單一些，較好實現的。
所以在C語言幾十年的發展中出現了各式各樣的編譯器，還有一些容易被誤解為編譯器的IDE。
這里列舉幾個主流的：
GCC
毫無疑問，GCC幾乎是unix及linux系統中最通用的編譯器套件，幾乎所有的linux發行版都預裝了GCC作為C語言的默認編譯器。除了對C語言的支持，GCC還支持C++、Objective-C等多種語言。GCC早在1987就由Richard Stallman作為GNU計劃的一部分發布。
Clang
Clang是近幾年新興的C/C++以及Objective-C的編譯器，Apple是其主要投資者，其最初的開發者已加盟Apple。雖說是新興，但其對C/C++標準的支持不亞於GCC等老牌編譯器，並且外部介面和GCC完全兼容，並且因其模塊化、錯誤提示完善等優點已經越來越受到重視。一些如FreeBSD等項目已將clang作為默認編譯器。
其實Clang並不是一個完整的編譯器，而是作為同一批開發者開發的另一個備受關注的虛擬機（類似於JVM）的llvm的一個前端開發，只是負責將C語言源碼編譯為llvm IR的中間語言，再由llvm編譯為目標代碼，這樣做可以讓其可移植性更好。
Microsoft Visual C++
作為擁有可視化集成編程系統的編譯器，VC被很多使用Windows作為開發環境的初學者使用。詳見網路的介紹
http://ke..com/view/2070966.htm？fromtitle=vc&fromid=7792954&type=syn#viewPageContent
D. Impala中 LLVM 的交叉編譯、調用過程
[TOC]
Impala 使用的 LLVM JIT，首先通過 Clang 將源碼編譯成了 LLVM IR 文件，然後通過腳本將 IR 文件裝成可載入的二進制文件，BE 進程在運行過程中，通過 LLVM 的載入介面，把二進制文件載入進來使用。
待編譯的文件通過codegen/ impala-ir.cpp 指定
impala-ir.cpp 文件主要的作用就是把需要產生 LLVM IR 的文件包含進來。
確定了哪些文件需要產生 LLVM IR 之後，就開始生成 IR 的二進制文件了。大致流程如下：
這個階段生成最初始的bc文件，使用的是 CLang 的編譯工具。命令可見codegen/CMakeFiles.txt
生成的結果是 impala-sse-tmp.bc 文件。
使用LLVM 優化工具，對原始的 bc 文件進行優化。命令可見codegen/CMakeFiles.txt
生成的結果就是impala-sse.bc。
這一步使用的是Impala 自定義的一個腳本 file2array.sh ，將優化後的 bc 文件轉換為可載入的二進制c 文件。命令可見codegen/CMakeFiles.txt。
生成的結果是impala-sse-ir.cc。這個文件內部就是用一個數組存放二進制的值。
be 進程就是通過讀取 impala_sse_llvm_ir 數組，把 LLVM IR載入到進程中。
file2array.sh 腳本其實就是使用 xxd -i < impala-sse-ir.cc 命令把bc 文件內容轉成 c 語言的二進制形式。
LlvmCodeGen 類通過 CreateImpalaCodegen 介面實例化 codegen 對象。 CreateImpalaCodegen 最終會調用 CreateFromMemory ，在 CreateFromMemory 中就是將上文中生成的 impala_sse_llvm_ir 數組通過 LLVM 介面載入進來。
完成載入後，就可以通過 GetFunction 獲取指定的 IR 函數了。
所有的函數名及描述，定義在 impala-ir-names.h 和 impala-ir-functions.h ，這兩個文件是有對應關系的，都是通過gen_ir_descriptions.py生成。
impala-ir-names.h 定義了數組 FN_MAPPINGS ，存儲函數名和枚舉值的映射關系，如下：
impala-ir-functions.h定義了所有函數的枚舉值，如下：
通過 GetFunction 獲取函數的時候，因為有了 FN_MAPPINGS 存儲的映射關系，可以通過傳入枚舉值或者字元串符號查找函數。
在 InitializeLlvm 方法中會使用 FN_MAPPINGS ，對載入的 llvm 函數進行校驗。
E. 如何利用LLVM寫一個編譯器
LLVM有自己的教程，如果你只想做個玩具，那可以首先試著實現LLVM Tutorial: Table of Contents的Kaleidoscope。深入的，請看他的文檔http://llvm.org/docs/
Kaleidoscope是一個範式簡單的腳本語言，教程里的詞法，語法分析都是手寫的，基本流程就是詞法語法解析，利用LLVM的API生成中間代碼並執行。
我用visual studio編譯的LLVM(version 3.6)實現過Kaleidoscope，我遇到的坑不少，如果你想以visual studio編譯的LLVM實現Kaleidoscope，你可能同樣會遇到
1. LLVM的生成目標對象為ELF格式，在windows下使用JIT的API時會出現incompatible object format的錯誤警告，需要在通過重新設定Mole的triple，我的PC的getTargetTriple的結果是「i686-pc-windows-msvc」，直接在後面再加上「-elf」即可
TheMole->setTargetTriple("i686-pc-windows-msvc-elf");
2. LLVM不支持windows下通過動態鏈接導出函數，如果需要使用C/C++的函數，需要通過addSymbol進行注冊
llvm::sys::DynamicLibrary::AddSymbol(/*std::string("_") +*/ "printd", &printd);
3. Kaleidoscope里使用的JIT的查找函數的API，getPointerToFunction已經被棄用了，需要替換為getFunctionAddress
F. RHEL linux下llvm的安裝。安裝出現的錯誤如下，怎麼解決或者知道怎麼編譯，教一下。
缺少關聯的文件。
needed by `lib/Target/AArch64/Utils/CMakeFiles/LLVMAArch64Utils.dir/AArch64BaseInfo.cpp.o'.
G. Go語言編譯器TinyGo，基於LLVM，在微控制器和小系統上編譯和運行
TinyGo是一個為微控制器、WebAssembly(Wasm)和命令行工具等小型場景設計的Go語言編譯器。TinyGo重用了Go語言工具和LLVM使用的庫，以編譯用Go語言編寫的程序。目前，該項目在GitHub上已經積累了10.1k的Star。
如下為一個示常式序，當運行在任何支持的帶板載LED的主板上時，則會點亮內置LED。
上述程序可以在單片機、Adafruit ItsyBitsy M0微控制器或任何支持的帶內置LED的板上進行編譯和不需要修改的運行，只要設置正確的TinyGo編譯器目標即可。例如，設置如下目標可以編譯和點亮 單片機。
項目概述
TinyGo項目旨在將Go語言引入到具有單進程或核心的微控制器和小系統。TinyGo類似於emgo，但主要的區別在於作者想要保留Go內存模型。另一個區別在於TinyGo在內部使用LLVM，因而可以獲得更小更高效的代碼以及更高的靈活性。
創建TinyGo項目的初衷是，如果Python可以在微控制器上運行，Go語言當然也應該能夠在更低級微設備上運行。
支持設備
你可以為微控制器、WebAssembly和Linux編譯TinyGo程序。目前，TinyGo支持以下85種微處理器板。
更多技術細節請參閱原項目。