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种微处理器板。
更多技术细节请参阅原项目。