llvm编译代码

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. 比较gcc，llvm和商用编 译器的性能差异，说明是什么原因导致差异 的出现

Apple在LLVM GCC4.2编译器中，通过XCode中的提示接口显式地为程序员提供是否将目标代码编译为ARM的选项。而在Apple LLVM3.0中，此选项没有了。
由于采用ARMv7A架构的Apple A4/A5处理器拥有Thumb-2指令集，使得Thumb代码在确保紧凑性的同时又进一步提升了计算能力。因此，Apple将工程配置默认设置为编译为Thumb代码。
而又由于LLVM的编译选项基本与GCC兼容，因此我们只需要在编译选项中手动加入-marm即可。
而传统GCC的编译选项只有-mthumb，它默认将代码编译为ARM指令集，因此可能没有提供-marm的编译选项。不过-marm在Apple LLVM3.0中确实奏效了。

C. llvm怎样将中间代码编译为可执行二进制文件

预编译。编译器将你的.c、.cpp源代码，通过解释其中的预编译指令，将源代码转换成相应的没有任何预编译指令的代码。

编译、优化。将上一步的代码编译成汇编指令，并作一定优化，形成对应的.s汇编代码
汇编。将.s文件汇编成机器码，形成对应的.o目标文件，此时是不可执行的二进制文件。生成对应的清单文件。为了连接需要，还会生成未定向符号表、导出符号表、地址重定向表等等。
连接。先根据对应的清单文件、连接文件及之间的调用关系，决定所有的目标文件及引用的库文件在最后可执行文件中的位置；然后做一些其他事情，比如根据符号表等将目标文件中的符号地址补全等等；最终得到可执行文件。
这只是我个人的简单理解，更详尽的解答都可以写成好几本书了=_=望采纳~

D. 如何编译llvm+clang+libc

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/ex...

E. 怎么用llvm编译器编写c语言

LLVM的帮助。对于这个工具,我不知道改怎么去形容它,但是他给我的这个编译器的确带... 我们使用的工具是基于C/...LLVM是构架编译器(compiler)的框架系统，以C++编写而成，用于优化以任意程序语言编写的程序的编译时间(compile-time)、链接时间(link-time)、运行时间(run-tim...

F. LLVM每日谈之一 LLVM是什么

写在前面的话： 最近接触llvm比较多，在这个上面花了不少的时间。感觉llvm要完全理解透是个很不容易的事情，需要在学习过程中好好的整理下自己的思路。刚好又阅读了开源项目Storm的作者Nathan Marz的博客《You should blog even if you have no readers》，就打开自己的blog，开始了这个llvm每日谈的系列。希望自己能坚持的久一点，多写写llvm的每个方面，多写写自己的理解。 llvm是low level virtual machine的简称，其实是一个编译器框架。llvm随着这个项目的不断的发展，已经无法完全的代表这个项目了，只是这种叫法一直延续下来。 llvm是一个开源的项目。它最早的时候是Illinois的一个研究项目，主要负责人是Chris Lattner，他现在就职于Apple. Apple 目前也是llvm项目的主要赞助者之一。 llvm的主要作用是它可以作为多种语言的后端，它可以提供可编程语言无关的优化和针对很多种CPU的代码生成功能。此外llvm目前已经不仅仅是个编程框架，它目前还包含了很多的子项目，比如最具盛名的clang. llvm的优点是开源，有一个表达形式很好的IR语言，模块化作的特别好。 llvm这个框架目前已经有基于这个框架的大量的工具可以使用。 llvm的官方网站地址是：llvm.org。在这里可以下载最新的发布代码，也可以找到介绍llvm的相关文档。 附录：llvm目前支持的工具(描述来自网络) llvm-as 将人类可读的 .ll 文件汇编成字节代码 llvm-dis 将字节代码文件反编成人类可读的 .ll 文件 opt 在一个字节代码文件上运行一系列的 LLVM 到 LLVM 的优化 llc 为一个字节代码文件生成本机器代码 lli 直接运行使用 JIT 编译器或者解释器编译成字节代码的程序 llvm-link 将几个字节代码文件连接成一个 llvm-ar 打包字节代码文件 llvm-ranlib 为 llvm-ar 打包的文件创建索引 llvm-nm 在 字节代码文件中打印名字和符号类型 llvm-prof 将 'llvmprof.out' raw 数据格式化成人类可读的报告 llvm-ld 带有可装载的运行时优化支持的通用目标连接器 llvm-config 打印出配置时 LLVM 编译选项、库、等等 llvmc 一个通用的可定制的编译器驱动 llvm-diff 比较两个模块的结构 bugpoint 自动案例测试减速器 llvm-extract 从 LLVM 字节代码文件中解压出一个函数 llvm-bcanalyzer 字节代码分析器 （分析二进制编码本身，而不是它代表的程序） FileCheck 灵活的文件验证器，广泛的被测试工具利用 tblgen 目标描述阅读器和生成器 lit LLVM 集成测试器，用于运行测试

G. 编译器二：LLVM和GCC的区别

GCC: GNU Compiler Collection
GCC属于传统编译器，传统编译器的工作原理基本上都是三段式的，可以分为前端（Frontend）、优化器（Optimizer）、后端（Backend）。前端负责解析源代码，检查语法错误，并将其翻译为抽象的语法树（Abstract Syntax Tree）。优化器对这一中间代码进行优化，试图使代码更高效。后端则负责将优化器优化后的中间代码转换为目标机器的代码，这一过程后端会最大化的利用目标机器的特殊指令，以提高代码的性能。
事实上，不光静态语言如此，动态语言也符合上面这个模型，例如Java。Java Virtual Machine也利用上面这个模型，将Java代码翻译为Java bytecode。这一模型的好处是，当我们要支持多种语言时，只需要添加多个前端就可以了。当需要支持多种目标机器时，只需要添加多个后端就可以了。对于中间的优化器，我们可以使用通用的中间代码。
这种三段式的结构还有一个好处，开发前端的人只需要知道如何将源代码转换为优化器能够理解的中间代码就可以了，他不需要知道优化器的工作原理，也不需要了解目标机器的知识。这大大降低了编译器的开发难度，使更多的开发人员可以参与进来。
虽然这种三段式的编译器有很多有点，并且被写到了教科书上，但是在实际中这一结构却从来没有被完美实现过。做的比较好的应该属Java和.NET虚拟机。虚拟机可以将目标语言翻译为bytecode，所以理论上讲我们可以将任何语言翻译为bytecode，然后输入虚拟机中运行。但是这一动态语言的模型并不太适合C语言，所以硬将C语言翻译为bytecode并实现垃圾回收机制的效率是非常低的。
GCC也将三段式做的比较好，并且实现了很多前端，支持了很多语言。但是上述这些编译器的致命缺陷是，他们是一个完整的可执行文件，没有给其它语言的开发者提供代码重用的接口。即使GCC是开源的，但是源代码重用的难度也比较大。
LLVM: Low Level Virtual Machine
LLVM最初是[Low Level Virtual Machine]的缩写，定位是一个虚拟机，但是是比较底层的虚拟机。它的出现正是为了解决编译器代码重用的问题，LLVM一上来就站在比较高的角度，制定了LLVM IR这一中间代码表示语言。LLVM IR充分考虑了各种应用场景，例如在IDE中调用LLVM进行实时的代码语法检查，对静态语言、动态语言的编译、优化等。
LLVM与GCC在三段式架构上并没有本质区别。LLVM与其它编译器最大的差别是，它不仅仅是Compiler Collection，也是Libraries Collection。举个例子，假如说我要写一个XYZ语言的优化器，我自己实现了PassXYZ算法，用以处理XYZ语言与其它语言差别最大的地方。而LLVM优化器提供的PassA和PassB算法则提供了XYZ语言与其它语言共性的优化算法。那么我可以选择XYZ优化器在链接的时候把LLVM提供的算法链接进来。LLVM不仅仅是编译器，也是一个SDK。

H. 如何用llvm-obfuscator混淆 js

LLVM是什么？
（1）LLVM是lowlevel virtual machine的简称，是一个编译器框架。苹果公司的Xcode 4.0之后用的都是LLVM编译器。
（2）LLVM 诞生于2003.10伊利诺伊大学香槟分校，创始人ChrisLattner，现任苹果公司‘开发者工具’部门的主管。

二、 LLVM-Obfuscator 是什么?

（1）LLVM-Obfuscator 是瑞士西北应用科技大学安全实验室针对LLVM编译组件开发的代码混淆工具，该工具完全开源，目的是为了增加逆向工程的难度，保证代码的安全性。
（2）Obfuscator-llvm最新版本集成了LLVM-3.4编译器，并且兼容LLVM支持的所有语言（C,C++, Objective-C, Ada and Fortran）和平台(x86, x86-64, PowerPC, PowerPC-64,ARM, Thumb, SPARC, Alpha, CellSPU, MIPS, MSP430, SystemZ,and XCore)。
纯手打，望采纳！

I. llvm 3.7,128bits啥意思

LLVM 是 Low Level Virtual Machine （低级虚拟机）的简称，这个库提供了与编译器相关的支持，可以作为多种语言编译器的后台来使用。能够进行程序语言的编译期优化、链接优化、在线编译优化、 代码生成。LLVM的项目是一个模块化和可重复使用的编译器和工具技术的集合。LLVM是伊利诺伊大学的一个研究项目，提供一个现代化的，基于SSA的编 译策略能够同时支持静态和动态的任意编程语言的编译目标。自那时以来，已经成长为LLVM的主干项目，由不同的子项目组成，其中许多正在生产中使用的各种 商业和开源的项目，以及被广泛用于学术研究。
LLVM 是 Illinois 大学发起的一个开源项目，和之前为大家所熟知的JVM 以及 .net Runtime这样的虚拟机不同，这个虚拟系统提供了一套中立的中间代码和编译基础设施，并围绕这些设施提供了一套全新的编译策略（使得优化能够在编译、 连接、运行环境执行过程中，以及安装之后以有效的方式进行）和其他一些非常有意思的功能。
对于普通的开发人员来说，LLVM计划提供了越来越多的可以使用、编译器以外的其他工具。例如代码静态检查工具 LLVM/Clang Static Analyzer，是一个 Clang 的子项目，能够使用同样的 Makefile 生成 HTML 格式的分析报告。

J. 如何利用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