编译点滴 » elf

前瞻-全时优化和LLVM-2

erlv — Thu, 29 Apr 2010 04:14:19 +0000

上篇文章，以论文为主要依据，介绍了LLVM的概况和中间表示，本篇关注论文的后半部分内容–架构设计和LLVM的整体评测：

LLVM的架构设计：

总览

LLVM的架构设计以让传统的链接时，安装时，运行时和空闲时代码转换都能透明地在LLVM中间表示上展开为目的。上图就是LLVM的高层设计架构。包括静态的编译器前端用于生成LLVM中间表示；连接器用于做连接时优化，尤其是过程间优化。连接器的输出被JIT或者机器代码生成器生成机器代码。在机器代码生成时，可以通过插入低代价的抽样指令来测量运行时的profile，检测热代码，并将空闲时进行优化。

作者认为LLVM的这种架构具有五个优点，这些优点现阶段的编译器或虚拟机等都无法完全具备，它们是：

提供程序的高层信息
离线代码生成器
用户级的profiling和优化
透明的运行时模型
统一的全程序编译

作者比较了如今存在的一些系统，分析它们是否具备以上5点：

传统的源码级编译器：能提供2和4，但很难提供1，3，5.虽然也能提供过程间优化，但需要修改Makefile
一些商用编译器能够在链接时部分支持1和5，这也是用过将它们的中间表示信息输出到目标文件中。但无法在空闲时使用这些信息
高层虚拟机，如JVM和CLI能提供3，部分支持1. CLI部分支持5，因为它支持多语言代码，但很多底层系统代码只能作为不可控代码直接运行。
透明的二进制运行时优化系统，如Dynamo和Transmeta能提供2，4，5，但不能提供1，而且对3的支持只在运行时。
静态profile制导优化（PGO），能提供3代价是不再对其他阶段透明。另外PGO也有缺点：应用开发者很少用它；使用PGO意味着训练用的输入需要严格和用户行为一致；profiling信息是完全静态的。

当然LLVM也有自己的缺点，作者在文中提到两点：1，源程序语言相关优化需要在前端生成LLVM中间表示之前完成；2，编程语言需不需要一个庞大的运行时系统还有争议。

编译时：外部前端和静态优化

外部静态LLVM编译器(即前端)将源语言程序转换为LLVM虚拟指令集。每种静态编译器都要完成三个关键任务：进行语言相关优化，如使用高层函数优化闭包(closures); 将源程序转换为LLVM代码，并综合尽量多的LLVM类型信息，如指针、结构体和数组信息；启动LLVM的全局或过程间优化。其中第二个任务是外部编译器必须要完成的。LLVM的优化都被写成库的形式，方便前端使用。前端无需构建SSA，可以使用一个栈存放变量，于是就能用栈来实现SSA的构建了。对于所谓的高层语言相关优化，LLVM的观点是：将LLVM优化扩展到特定的转换要好过在编码时为特定语言投入大量的精力。

连接时和过程间优化

LLVM中，连接时是绝大部分分析和转换可以实现的首个编译阶段。LLVM现在包含一些过程间优化，包括：内容相关指针分析；调用图构建；定义-引用分析和过程间转换(内联，死全局变量删除、死参数删除、死类型删除、常数传播、数据越界检查删除、简单结构体域重排、自动存储分配等).LLVM中提供的编译和运行时优化器能加快过程间分析速度。编译时，汇总每个函数的过程间信息，并附在LLVM 代码中。链接时，过程间优化器以这些信息作为输入，而非重新从源码中得到信息。这种技术有效的缩短了编译实践，而且在链接时之前，并未破坏源码的结构。

离线和实时代码生成器

代码生成器用于运行代码前将LLVM中间表示转换为目标平台的机器语言(目前LLVM支持X86和Sparc V9平台).有两种方式实现这种转换，一是在链接时或安装时代码生成器静态地生成高效本地码，这时可以使用代价高的代码生成技术。如果用户打算使用运行时和离线优化器，LLVM中间表示将会附在可执行文件中，并且代码生成器会插入低代价的指令来识别常被执行到的代码区间。另外，LLVM还有一个实时执行引擎，直接在运行时启动代码转换器。

运行时程序行为采集和重优化

LLVM设计的目标之一是开发一种全新的普通应用运行时优化架构。程序执行中，识别最常被执行的路径，通常是热循环。识别出热循环后，复制热区域代码，并使用LLVM代码生成器，优化并生成机器码，并在原始代码和新机器码之间插入一个分支指令。这种机制很强大，理由有三：本地代码生成恩公使用经典算法来产生高性能代码；因为本地代码生成器和运行时优化器都是LLVM的一部分，因此能很好的协同工作，让运行时优化起从代码生成器中得到很好支持；运行时优化起能从LLVM的中间表示中得到高层信息以便实施高度优化。

用户行为信息制导的离线重优化

因为LLVM中间表示能保存，使得应用程序的空闲时离线优化能透明地在用户系统上进行。该优化器可以简单修改连接时过程间优化器来得到，只需要把重点放在目标机相关和反馈信息指导优化即可。

LLVM的评测和应用

评测LLVM

作者评测了LLVM的四个方面：语言无关类型系统的完备性；高级语言特性到LLVM中间表示转换如何实现；LLVM中间表示的复杂度；LLVM的编译速度。

类型系统完备性方面，LLVM使用流敏感，域敏感和内容敏感的指针分析算法来保证LLVM类型系统的可靠性。

高级语言特性方面，作者给出了C++中的隐式调用、模板、基类、虚函数表、例外如何使用LLVM中间表示表达。

LLVM中间表示的复杂度方面，作者对比了GCC3.3 O3下生成X86，Sparc可执行文件和LLVM中间表示文件的大小，结果显示LLVM中间表示大小和X86可执行文件大小相当，明显小于Sparc的可执行文件，作者相信这是LLVM的优势，因为LLVM中间表示使用无限多的寄存器，丰富的类型信息，控制流信息和数据流信息(SSA),而可执行代码没有这些信息。

LLVM的编译速度方面，作者给出了LLVM上几个过程间优化：DGE(aggressive Dead Global variable and function Elimination),DAE(aggressive Dead Argument and return value Elimination),inline转换时间并和GCC O3的编译时间对比，结果显示LLVM做以上三个过程间优化的编译时间要大大短于GCC O3的编译时间，而且GCC O3还没有过程间优化，作者也给出了LLVM的优化效果。

LLVM的应用

LLVM中已经实现的几种技术：如数据结构体分析(Data Structure Analysis)和自动查询分配(Automatic Poll Allocation)都得益于LLVM的架构。

SAFECode:一个安全的低级中间表示和运行环境。该中间表示基于LLVM中间表示，目的是增强程序的存储安全。除了运行时优化外，SAFECode几乎使用了LLVM架构中的所有结构。

虚拟指令集计算机的外部指令系统设计：虚拟指令集处理器可以使用两个完全不同指令集。外在的虚拟指令级和隐藏的内部实现指令集。LLVM的中间表示就能作为一种外部虚拟指令集。

与LLVM相关的工作:

高层语言虚拟机，如SmallTalk，Self，JVM和CLI，需要特定的对象模型和运行时系统支持，但因为太高层，其他语言(如C++)可能很难在该虚拟机上运行。为了可移植性，中间表示需要严格的类型安全，这也限制了对多语言的支持。类型安全的检测也使得很多优化无法进行。

虽然微软的CLI有些支持不同语言的特性。但CLI支持多语言的unmanaged方式使得，部分语言不能用CLI的中间表示完整表达，优化机会也就随之丧失。

Omniware虚拟机和LLVM比较像，因为都实现抽象的低层RISC指令级。但Omniware缺乏高层的类型信息。

Kistler和Franz给出了一个编译器架构，初始代码生成很简单，依靠程序运行行为指导接下来的优化。但不能支持任意语言，而且也没有透明的运行时系统。

类型化的中间表示方面，也有很多相关工作。但多数都为了类型安全，提取高层语言信息。LLVM则重点放在在静态编译优化之外使得经典的程序分析和优化算法能够实现。

统一、通用的中间表示方面也有了不少研究。但几乎都失败了。这些中间表示大多从AST级抽取信息并尽量支持所有源语言特性。LLVM的中间表示更像汇编，使用很小的类型集和低层操作。

过程间优化方面，有的为给定处理器做基于汇编的优化；有些从静态编译器中得到附加信息。但这些都没有考虑运行时和离线优化支持。

也有一些系统提供透明的运行时优化。但这些系统都只是努力的优化机器码。LLVM则是以提供类型，数据流和精确控制流图为目标。

来仔细看看GCC 4.5.0

erlv — Fri, 16 Apr 2010 04:39:51 +0000

距离GCC 4.4的发布一年之久，GNU终于发布GCC 4.5了。新版本带来了很多新特性，包括使用MPC库在编译时完成复杂的算术计算，C++0x支持增强，使用部分Graphite完成自动并行化，支持新的ARM处理器，Intel Atom优化和调优支持，以及AMD Orochi优化支持等。今年稍晚发布的Fedora 14,Ubuntu 10.10,OpenSUSE 11.3，都将有GCC4.5，估计Gentoo马上就会有支持了，磨拳擦掌准备试用喽：）详细支持如下：

总体说明：

编译GCC需要MPC库
故纸堆里的旧系统和很久没有更新和测试的系统在GCC4.5中被标记为待放弃，包括IRIX, Solaris 7, Tru64 UNIX V5.1.
GCC4.4中标记为待放弃的支持被放弃
移除Itanium 1变种支持，但Itanium2编译的程序能在Itanium1上正确执行
GCC生成的调试信息包括了更多DWARF 3的特性，甚至包含了DWARF4的一些特性.GDB7.0之前的版本将无法使用这些特性.所以调试GCC4.5编译的程序需要使用GDB7.0及以上版本.也可以使用选项 -gdwarf-s -gstrict-dwarf来禁止生成DWARF4信息，或者-gdwarf-2 -gstrict-dwarf让GCC严格执行DWARF2标准.
X86上，浮点运算在GCC4.5上使用严格C99语法编译时，可能会运行变慢。这是为了和标准一致，可以通过选项-fexcess-precision=fast来避免严格的标准限制。
noinline属性不再能阻止整个函数拷贝。但可以通过新的属性noclone做到。

改进：

-save-temps可以增加参数，该功能让用户可以在并行编译的时候得到编译器的中间文件，但不会在不同的文件夹中使用相同的文件名从而干扰比起。
调试信息目标文件也都被放在了同个文件夹下，而不是当前工作目录，这样用户可以在并行编译的时候得到调试信息。
集成了MPC库，这样可以让GCC在编译时更精确的评估复杂的算术运算。GCC也可以通过它，对于常数作参数的数学运算类内建函数调用，直接在编译时使用相等的返回值来代替之。包括下列内建函数：cacos, cacosh, casin, casinh, catan, catanh, ccos, ccosh, cexp, clog, cpow, csin, csinh, csqrt, ctan和ctanh。
新的链接时优化器(-flto),打开此选项后，GCC会针对每个输入文件，产生bytecode的表示形式，并将其写入每个目标文件的特定ELF区內。链接时，从这些ELF区內读取函数体，并将其实体化为转换单元。这样就可以使得过程间优化能在不同的文件间进行(甚至不同语言间),进而可能提升性能。使用此功能需要在编译时和链接时都增加-flto选项。如果不需要程序输出任何符号，可以联合-fwhopr和-fwhole-program来让过程间优化器执行更加激进的优化。
增强自动并行化，现在支持外层循环的并行化。
自动并行化能作为Graphite的一部分来打开。在选项-ftree-parallelize-loops=的基础上增加-floop-parallelize-all能打开基于Graphite的优化。(注:Graphite是GCC中使用多面体模型做循环优化的部分)
重写基于严格指针的优化架构，会提高生成代码的效率。基于严格指针的优化在打开-fno-strict-aliasing后可用。
增加关于函数传参的新优化。试图改变函数原型，避免无用传递，仅传递结构体中特定部分，并将引用传参改为值传参。-O2，-Os及以上级别默认开启此优化。
优化异常控制代码。

新语言支持和特定语言改进

所有语言：-fshow-colum选项默认打开，错误信息现在有列信息。
C类语言：若#include的文件未找到，编译器会立即退出；增加一个新内建函数__builtin_unreachable()；增加-Wlogical-op选项，对可能存在的逻辑错误，报警告；嵌入式汇编增加goto特性，允许汇编中的语句直接跳到C中的标号处；C++0x原始strings(raw string)支持；deprecatd树形现在可以增加可选字符串参数,如__attribute__((deprecated(“text string”))),这样，deprecation警告会和字符串一同打印。
其他针对各个语言的详细细节请参考官方release。

其他改进：

插件支持：可以不通过改变编译器代码来扩展编译器功能。-fplugin=file.so能指定GCC载入动态链接文件file.so，并将其作为编译器的一部分执行。更多的细节请参考相关文档。
安装文件夹稍有变动。

参考：

http://gcc.gnu.org/gcc-4.5/changes.html

GNU工具链学习笔记

erlv — Mon, 08 Mar 2010 12:43:40 +0000

1..so为动态链接库，.a为静态连接库。他们在Linux下按照ELF格式存储。ELF有四种文件类型。可重定位文件(Relocatable file,*.o，*.a),包含代码和数据，可用来连接成可执行文件或共享目标文件;可执行文件(Executable File),ELF可执行文件；共享目标文件(Shared Object File,*.so),包含代码和数据；核心转储文件(Core Dump File),进程意外终止时，系统将该进程的地址空间内容和其他信息保存到该文件中。
file命令可以查看。
2，Objdump程序，来自binutils，可以查看Object file内的结构。-h：打印各个段基本信息；-s所有段内容以16进制打印;-d:将所有包含指令的段反汇编。
3, ar -t libc.a；查看libc.a压缩了那些.o文件。
4, collect2 是ld连接器的包装，它调用ld链接目标文件，并对结果做处理，包括收集所有与程序初始化相关的信息并构造初始化结构。
5，readelf：查看ELF文件。 -s:打印符号信息；

6, size *.o : 用于查看ELF文件代码段，数据段和BSS(Block Started by Symbol,为未初始化的全局变量和局部静态变量预留位置)段的长度。
7, nm：查看目标文件的符号信息。
8，C运行时库GlibC,由两部分组成，头文件和二进制库，前者多在/usr/include下，后者主要是C语言的标准库，有静态(/usr/lib/libc.a)和动态(/lib/libc.so.6)两个.另外还有/usr/lib/crt1.o(含程序入口函数_start,负责初始化libc和调用main),/usr/lib/crti.o(负责main函数执行前全局和静态对象的构造)和/usr/lib/crtn.o(负责main函数执行后，全局和静态对象的析构)三个辅助程序运行的库。链接器会收集所有输入目标文件中对全局和静态对象的构造/析构操作，合并到输出文件的构造和析构操作中。
9.GCC中的几个库文件，这些库文件都在GCC的安装目录下，Gentoo系统中的目录为/usr/lib/gcc/i686-pc-linux-gnu/4.4.3/。crtbeginT.o和crtend.o,负责C++全局构造和析构的目标文件，因为glibc只是C语言运行库，GCC实现C++语言，所以C++中构造和析构需要glibc中的C语言构造/析构和GCC中相应的构造/析构。libgcc.a用来对付GCC在多平台上运行时的差异问题；libgcc_eh.a包含了支持C++异常处理的平台相关函数。libgcc_s.so是libgcc.a的动态链接版本。
10.ldd 打印共享库依赖关系。

以上内容摘抄自《程序员的自我修养 –链接，装载与库》

WebKit和Firefox的JavaScript性能对比

erlv — Fri, 22 Jan 2010 14:37:22 +0000

严格的说WebKit仅仅是个浏览器核心，采用该核心的浏览器很多，如国内的搜狗浏览器，遨游浏览器。其他的如google的chrome(Windows平台，linux平台下为chromium),epiphany(linux平台下，gnome2.28版本之后),苹果的Safari 都采用了webkit的内核。Firefox则是采用Gecko的内核，这是NetScape公司开发的内核，后来开源，mozilla继续开发。另外，现在还有另外两种常见的浏览器内核，Trident主要用在IE系列上，Presto主要用在Opera上。

这篇文章仅仅针对浏览器处理JavaScript的性能作比较，主要在X86平台和龙芯平台。先来解释一下JavaScript，JavaScript是互联网内较为常用的脚本语言，面向对象，主要在浏览器内解释执行，用于生成动态网页，因为很多语言特性受Java影响，所以叫JavaScript。通过JavaScript，浏览器可以运行服务器想要在访问者终端上运行的一些计算程序，以达到更好的浏览体验。

再说说浏览器内核和JavaScript的关系，其实JavaScrip脚本的执行仅仅是浏览器内核的一部分，其他的还有Html语言的解释执行，网页的呈现等等也是内核要做的。之所以这么关心浏览器核心对JavaScript脚本的处理情况，是因为现在的很多应用不再是简单的网页浏览，如gmail，google reader，gooe wave还有一些网页3D特效等等都需要在客户机上作计算，这就需要JavaScript大显身手了。而且越来越多的应用依赖JavaScript，所以现在浏览器对JavaScript的处理速度直接影响着用户体验。目前WebKit的JavaScript引擎SquirrelFish，JavaScript的引擎是SpiderMonkey

目前JavaScript在大多数平台上的处理是靠解释执行的，又因为是动态类型，面向对象。。。，决定了JavaScript执行效率低，所以就诞生了各种针对JavaScript的优化，也有了测试JavaScipt解释器性能的BenchMark，目前常用的是Sunspider和google V8，这篇文章中的对比针对Sunspider测试集。

另外还要说说JIT，Just In time，转换，将部分程序代码直接转换成机器码执行，这种技术在运行时优化中比较常用，JavaScript是解释器，所以JIT在解释器中也是很重要的优化手段。目前X86的webkit和Firefox默认就有JIT支持，但龙芯平台上还没有，本博也是最早对龙芯2F平台有JIT支持的Webkit和firefox JavaScript引擎作对比的，目前这两个JIT都还没有进入官方的代码库中，感兴趣的朋友可以在下面的前两个链接中找到相关源码。其中webkit的补丁还要做些宏的修改，改动不大。这两个都是从官方源码库checkout出来并修改之后的。其中firefox的JIT部分是由ZSC大牛写出来的，详细的讨论贴和测试结果可以在龙芯论坛看到，见下面的第三个链接。
x86下epiphany(webkit内核)和firefox开了jit之后的性能，如下

webkit Total:                  833.6ms +/- 2.1%
firefox Total:                 1774.4ms +/- 2.7%

（测试环境是我的笔记本 intel Pentium t2390,开了频率调节，所以波动较大)、两个差距：

TEST                   COMPARISON            FROM                 TO             DETAILS

=============================================================================

** TOTAL **:           2.13x as fast     1774.4ms +/- 2.7%   833.6ms +/- 2.1%     significant

=============================================================================

  3d:                  2.96x as fast      257.2ms +/- 2.1%    87.0ms +/- 1.0%     significant
    cube:              3.36x as fast       79.2ms +/- 1.7%    23.6ms +/- 2.9%     significant
    morph:             1.52x as fast       50.4ms +/- 1.4%    33.2ms +/- 3.1%     significant
    raytrace:          4.23x as fast      127.6ms +/- 3.0%    30.2ms +/- 3.4%     significant

  access:              3.26x as fast      237.0ms +/- 4.7%    72.8ms +/- 2.8%     significant
    binary-trees:      8.82x as fast       67.0ms +/- 4.4%     7.6ms +/- 9.0%     significant
    fannkuch:          3.48x as fast       98.2ms +/- 0.6%    28.2ms +/- 3.7%     significant
    nbody:             2.50x as fast       51.4ms +/- 10.3%    20.6ms +/- 3.3%     significant
    nsieve:            -                   20.4ms +/- 56.6%    16.4ms +/- 4.2% 

  bitops:              1.42x as fast       53.8ms +/- 1.9%    38.0ms +/- 0.0%     significant
    3bit-bits-in-byte: *3.10x as slow*      2.0ms +/- 0.0%     6.2ms +/- 9.0%     significant
    bits-in-byte:      -                   11.0ms +/- 8.0%    10.4ms +/- 6.5%
    bitwise-and:       *2.33x as slow*      3.0ms +/- 0.0%     7.0ms +/- 0.0%     significant
    nsieve-bits:       2.62x as fast       37.8ms +/- 1.5%    14.4ms +/- 4.7%     significant

  controlflow:         8.76x as fast       50.8ms +/- 2.0%     5.8ms +/- 9.6%     significant
    recursive:         8.76x as fast       50.8ms +/- 2.0%     5.8ms +/- 9.6%     significant

  crypto:              2.34x as fast       93.8ms +/- 1.7%    40.0ms +/- 2.2%     significant
    aes:               2.57x as fast       54.0ms +/- 3.6%    21.0ms +/- 4.2%     significant
    md5:               2.62x as fast       26.2ms +/- 2.1%    10.0ms +/- 0.0%     significant
    sha1:              1.51x as fast       13.6ms +/- 5.0%     9.0ms +/- 0.0%     significant

  date:                1.87x as fast      275.2ms +/- 2.0%   147.0ms +/- 1.0%     significant
    format-tofte:      2.75x as fast      149.0ms +/- 1.0%    54.2ms +/- 1.0%     significant
    format-xparb:      1.36x as fast      126.2ms +/- 4.0%    92.8ms +/- 1.7%     significant

  math:                1.12x as fast       89.8ms +/- 1.8%    80.2ms +/- 21.7%     significant
    cordic:            2.13x as fast       43.4ms +/- 3.3%    20.4ms +/- 9.2%     significant
    partial-sums:      *1.41x as slow*     34.4ms +/- 2.0%    48.6ms +/- 38.2%     significant
    spectral-norm:     1.07x as fast       12.0ms +/- 0.0%    11.2ms +/- 12.2%     significant

  regexp:              3.73x as fast      125.4ms +/- 15.5%    33.6ms +/- 2.0%     significant
    dna:               3.73x as fast      125.4ms +/- 15.5%    33.6ms +/- 2.0%     significant

  string:              1.80x as fast      591.4ms +/- 3.3%   329.2ms +/- 1.6%     significant
    base64:            *1.24x as slow*     28.4ms +/- 2.4%    35.2ms +/- 1.6%     significant
    fasta:             1.71x as fast      133.0ms +/- 2.3%    78.0ms +/- 4.6%     significant
    tagcloud:          2.81x as fast      169.4ms +/- 3.8%    60.2ms +/- 8.2%     significant
    unpack-code:       1.91x as fast      193.8ms +/- 4.4%   101.6ms +/- 2.7%     significant
    validate-input:    1.23x as fast       66.8ms +/- 5.8%    54.2ms +/- 6.4%     significant

龙芯上的JIT具体对比数据不便透漏，可以从下面第三个链接中找到第一版发布时的测试数据。这里仅仅给出一个对比。webkit之所以with GUI是使用编译出的迷你小浏览器中测试结果，no GUI是使用测试脚本跑出来的结果。

 Webkit with GUI Total:                  6723.4ms +/- 0.5%
        no GUI   Total:                  6355.8ms +/- 0.5%
 Firfox Total 7000 ms 左右。

注：龙芯中的JIT现在还不够成熟，其中Webkit的JIT仅是针对MIPS III做的，没有针对龙芯的特殊优化。

另外，X86中firefox的版本是3.5.7，龙芯中firefox的版本是3.7pre1.WebKit在X86中版本是epiphany的2.28中的版本，龙芯中为SVN中的2010-01-12 r53114。X86运行环境为Gentoo，Gcc4.4.2,Glibc2.11,龙芯运行环境是玲珑一体机，GCC4.3(龙梦修改版）,Glibc2.10。

对比结果可见：X86中WebKit浏览器的性能要明显优于Firefox，达到两倍之多。龙芯相比起来还有些差距，不过相信优化后龙芯的性能会更好。

参考

https://bugs.webkit.org/show_bug.cgi?id=30144

http://dev.lemote.com/code/firefox-3.7-loongson-jit

http://lemote.com/bbs/viewthread.php?tid=26687&extra=page%3D1

http://en.wikipedia.org/wiki/Google_Chrome

http://ineolee.com/pc/several-browser-core-introduction/

GCC中的pie和fpie选项

erlv — Thu, 07 Jan 2010 21:40:19 +0000

Position-Independent-Executable是Binutils,glibc和gcc的一个功能，能用来创建介于共享库和通常可执行代码之间的代码–能像共享库一样可重分配地址的程序，这种程序必须连接到Scrt1.o。标准的可执行程序需要固定的地址，并且只有被装载到这个地址时，程序才能正确执行。PIE能使程序像共享库一样在主存任何位置装载，这需要将程序编译成位置无关，并链接为ELF共享对象。

引入PIE的原因是让程序能装载在随机的地址，通常情况下，内核都在固定的地址运行，如果能改用位置无关，那攻击者就很难借助系统中的可执行码实施攻击了。类似缓冲区溢出之类的攻击将无法实施。而且这种安全提升的代价很小

谈到PIE就不得不说说Pax和Grsec内核。这两个东西都是为了构建坚不可摧到安全系统而准备的。PaX是Linux内核安全增强补丁，它能在两方面保证安全性，一是ASLR(Address Space Layout Randomization,地址空间分布随机化)，这是一种将所有数据装载到内存时都随机化地址的方式，当使用PIE选项编译应用时，PaX能将应用的地址做随机加法；二是能提供不可执行的内存空间，这样就能使得攻击者放入内存中的恶意代码不可执行。不过PaX官网上能支持的最新内核是2.6.27，已经是一年前的更新了。Grsec也时类似的内核补丁，更新较为频繁能支持最新的2.6.32内核。这两种方式都能将内核完全位置无关，除了Grub和Glibc中无法位置无关的汇编码。

PIE最早由RedHat的人实现，他在连接起上增加了-pie选项，这样使用-fPIE编译的对象就能通过连接器得到位置无关可执行程序。fPIE和fPIC有些不同。可以参考Gcc和Open64中的-fPIC选项.

gcc中的-fpic选项，使用于在目标机支持时，编译共享库时使用。编译出的代码将通过全局偏移表(Global Offset Table)中的常数地址访存，动态装载器将在程序开始执行时解析GOT表项(注意，动态装载器操作系统的一部分，连接器是GCC的一部分).而gcc中的-fPIC选项则是针对某些特殊机型做了特殊处理，比如适合动态链接并能避免超出GOT大小限制之类的错误。而Open64仅仅支持不会导致GOT表溢出的PIC编译。
gcc中的-fpie和-fPIE选项和fpic及fPIC很相似，但不同的是，除了生成为位置无关代码外，还能假定代码是属于本程序。通常这些选项会和GCC链接时的-pie选项一起使用。fPIE选项仅能在编译可执行码时用，不能用于编译库。所以，如果想要PIE的程序，需要你除了在gcc增加-fPIE选项外，还需要在ld时增加-pie选项才能产生这种代码。即gcc -fpie -pie来编译程序。单独使用哪一个都无法达到效果。
你可以使用file命令来查看当前的可执行文件是不是PIE的。

下面是本博编译helloword的显示。可以看出，可执行文件属性从executable变成了shared object.
$ gcc helloworld.c $ file a.out a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped $ gcc -fpie -pie helloworld.c $ file a.out a.out: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
接下来，我们就能实验了，使用strace命令来查看这两个a.out执行情况了。关于strace命令，可以参考strace命令介绍
在博主电脑上，有PIE时，执行第一个brk(0)系统调用时，返回的地址一直是变化的。而无PIE时，brk(O)系统调用返回地址一直不变。内容太多，不再贴出。

注：
linux系统调用brk()：
linux系统内部分配内存的系统调用，malloc()其实也是调用的brk().直接修改堆的大小，返回新内存区域的结束地址。

参考：
http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html

http://www.linuxfromscratch.org/hlfs/view/unstable/glibc-2.6/chapter02/pie.html

http://www.gentoo.org/proj/en/hardened/hardened-toolchain.xml
http://www.gentoo.org/proj/en/hardened/pax-quickstart.xml
http://www.kernel.org/doc/man-pages/online/pages/man2/brk.2.html
3rd Edition Page32 , Page395

Strace命令介绍

erlv — Mon, 04 Jan 2010 14:16:16 +0000

strace- system calls and signals trace.跟踪系统中调用和信号信息。
最简单的情况下，strace ls 会执行ls命令直到结束，监听记录ls进程执行过程中的系统调用信息和进程接收的信号，每个系统调用的名字、参数和返回值都打印到标准输出，也可以使用-o选项输出到文件。strace是很有用的调试工具，对于源码不可见的程序，非常有用，因为系统调用和信号是用户态和内核态之间交互的接口，strace将有助于程序员定位bug，
如下，为在博主电脑上运行$strace ls
的输出信息：execve("/bin/ls", ["ls"], [/* 65 vars */]) = 0 brk(0) = 0x805f000 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7792000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=123690, ...}) = 0 mmap2(NULL, 123690, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7773000 close(3) = 0 open("/lib/librt.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`\31\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=30552, ...}) = 0 mmap2(NULL, 33392, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb776a000 mmap2(0xb7771000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6) = 0xb7771000 close(3) = 0 open("/lib/libacl.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0@\32\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=26144, ...}) = 0 mmap2(NULL, 29028, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7762000 mmap2(0xb7768000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x5) = 0xb7768000 close(3) = 0 open("/lib/libc.so.6", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\20m\1\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1323292, ...}) = 0 mmap2(NULL, 1329448, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb761d000 mmap2(0xb775c000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13f) = 0xb775c000 mmap2(0xb775f000, 10536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb775f000 close(3) = 0 open("/lib/libpthread.so.0", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\360I\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=121931, ...}) = 0 mmap2(NULL, 98796, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7604000 mmap2(0xb7619000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14) = 0xb7619000 mmap2(0xb761b000, 4588, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb761b000 close(3) = 0 open("/lib/libattr.so.1", O_RDONLY) = 3 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\20\0\0004\0\0\0"..., 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=17788, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7603000 mmap2(NULL, 20656, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb75fd000 mmap2(0xb7601000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x3) = 0xb7601000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb75fc000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb75fc6c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb7601000, 4096, PROT_READ) = 0 mprotect(0xb7619000, 4096, PROT_READ) = 0 mprotect(0xb775c000, 8192, PROT_READ) = 0 mprotect(0xb7768000, 4096, PROT_READ) = 0 mprotect(0xb7771000, 4096, PROT_READ) = 0 mprotect(0x805d000, 4096, PROT_READ) = 0 mprotect(0xb77b0000, 4096, PROT_READ) = 0 munmap(0xb7773000, 123690) = 0 set_tid_address(0xb75fc728) = 19879 set_robust_list(0xb75fc730, 0xc) = 0 futex(0xbf999d90, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0xbf999d90, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, bf999da0) = -1 EAGAIN (Resource temporarily unavailable) rt_sigaction(SIGRTMIN, {0xb76083d0, [], SA_SIGINFO}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb76088c0, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0 uname({sys="Linux", node="erlv-laptop", ...}) = 0 brk(0) = 0x805f000 brk(0x8080000) = 0x8080000 open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=5129504, ...}) = 0 mmap2(NULL, 2097152, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb73fc000 mmap2(NULL, 1638400, PROT_READ, MAP_PRIVATE, 3, 0x2b6) = 0xb726c000 close(3) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, TIOCGWINSZ, {ws_row=48, ws_col=154, ws_xpixel=0, ws_ypixel=0}) = 0 open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 3 fcntl64(3, F_GETFD) = 0x1 (flags FD_CLOEXEC) getdents64(3, /* 11 entries */, 32768) = 328 getdents64(3, /* 0 entries */, 32768) = 0 close(3) = 0 fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7791000 write(1, "Segmentation WOPT-I.html WOPT-"..., 101Segmentation WOPT-I.html WOPT-I.html~ donkey.png gcc gcc~ lingccne_wrd1.sql.gz plugins themes ) = 101 close(1) = 0 munmap(0xb7791000, 4096) = 0 close(2) = 0 exit_group(0) = ?
对于每个系统调用，都给出了参数和返回值，如：execve("/bin/ls", ["ls"], [/* 65 vars */]) = 0
每个错误都给出了错误编号和出错提示信息：access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
从上面还可以看到，每个输出都清楚的打印了每个信号以及参数的符号，所以strace可读性很强。fstat64(3, {st_mode=S_IFREG|0644, st_size=5129504, ...}) = 0
从上面这行可以看出，对于结构体指针，都做了解析，所有成员都使用符号打印出来。

下面介绍几个strace中的选项：
-c 记录系统调用和每个系统调用中错误的类型和时间并在程序退出时打印汇总信息。
-f 像跟踪当前进程一样跟踪该进程创建的子进程。
-t/tt/ttt/T 输出信息时，加上不同的时间标签。
-e trace= 通过各种形式指定跟踪类型，有以下集中set,file,process,network,signal,ipc,desc

Gentoo中的交叉编译利器–crossdev

erlv — Thu, 31 Dec 2009 14:03:21 +0000

什么是Crossdev[I]

sys-devel/crossdev Available versions: 0.9.18-r10 ~0.9.19 **99999999 Installed versions: 0.9.18-r10(03:44:50 PM 11/29/2009) Homepage: http://www.gentoo.org/ Description: Gentoo Cross-toolchain generator
交叉编译时很多嵌入式开发必须的工具，因为资料太少，遇到的问题又很难解决，所以交叉的开发环境一直让很多程序员头疼。我们就来了解一下gentoo下如何构建交叉编译环境。
先说说工具链，工具链是用来组建一个系统的工具包集合，因为它们使用输入和输出连接在一起，所以称为链。通常工具链包括以下几部分：

binutils–用来生成二进制的基本工具(包括汇编器和连接起)

gcc–GNU编译器集(C和C++编译器)

glibc/uclibc/newlib–系统C语言库

linux-headers–系统文件库需要的内核头文件

gdb–GNU调试工具

一般的Gentoo系统都将工具链作为基础系统的一部分，并且将工具链配置为能生成本机的二进制文件。为了能编译其他平台上的二进制文件，就需要交叉工具链，Gentoo提供了一个简单但很强大的工具CrossDev来管理工具链，它可以编译安装任意GCC支持的交叉工具链，因为Gentoo将工具链的文件安装在平台特定的目录下，所以Crossdev得到的交叉工具链不会干扰到本地的工具链。手工编造一个交叉工具链太痛苦了。。。。

工具链使用的环境变量

工具链的环境变量总是让人很头疼，下面我们做个详细的介绍
变量名—生成交叉工具链时的含义—生成目标平台二进制文件时的含义
CBUILD–编译交叉工具链的平台—编译程序的平台
CHOST–交叉工具链运行的平台—使用交叉工具链生成的二进制文件将运行的平台
CTARGET–使用交叉工具链生成的二进制文件将运行的平台–使用交叉工具链生成的二进制文件将运行的平台(内容虽然重复，但设置它没有坏处，有些二进制包需要它)
ROOT–将要安装的虚/路径
PORTAGE_CONFIGROOT–portage能找到配置文件的虚/路径(如/etc/make.conf)
若我们有个AMD64的gentoo机器，和一个想要开发程序的ARM PDA。那上面的变量可以设置如下：
CBUILD–x86_64-pc-linux-gnu–x86_64-pc-linux-gnu
CHOST–x86_64-pc-linux-gnu–arm-unknown-linux-gnu
CTARGET–arm-unknown-linux-gnu–not set
ROOT—[not set -- defaults to /]—[/path/where/you/install]
PORTAGE_CONFIGROOT—[not set -- defaults to /]—-[/path/where/your/portage/env/for/arm/pda/is]

一些术语

cross-compiler CHOST！=CTARGET的工具链
canadian cross 加拿大式交叉编译CBUILD != CHOST && CHOST != CTARGET的工具链
CBUILD build system 编译二进制文件所使用平台
CHOST host system 运行二进制文件所使用平台
CTARGET target system 编译得到的二进制文件将要运行的平台
sysroot system root 编译器用来查找它的标准头文件和库的根目录
hardfloat 系统用来处理浮点数学运算的硬件浮点单元(FPU)
softfloat 若系统没有硬件FPU,就需要所有的浮点数使用定点数学运算近似
PIE 位置无关的执行(-fPIE -pie)
PIC 位置无关代码(-fPIC)
CRT C语言运行时

系统元组

系统元组标记整个系统的特征，具体的内容由GNU config项目规定。具体的模式是机器(machine)-类型(vendor)-内核(kernel)-操作系统(operating system)。比如，博主我的电脑上就是i686-pc-linux-gnu.下表是一些比较常见的配置

机器	类型	内核	操作系统
alpha arm / armeb avr / avr32 bfin cris hppa / hppa1.1 / hppa2.0 / hppa64 ia64 i386 / i486 / i586 / i686 m68k mips / mipsel / mips64 / mips64el nios / nios2 powerpc / powerpc64 sparc / sparcv8 / sparcv9 / sparc64 s390 / s390x sh / sh3 / sh4 / sheb / sh3eb / sh4eb / sh64 vax x86_64	gentoo pc softfloat [1] unknown	elf [2] freebsd6.2 linux mingw32 / mingw64 uclinux [3]	gnu [4] gnueabi [5] uclibc [6] uclibceabi

来说说这其中几个比较有趣的：

类型那部分几乎可以随便设置，

当操作系统指定为elf时，你就可以不用操作系统，而是直接把编译出的代码放到硬件上运行。

uclinux编译出的FLAT二进制文件，能在MMU不可用的Linux上运行

操作系统中指定gnu表明系统库为libc

言归正传，装我们的交叉编译器

我们的第一步当然是emerge -av crossdev
这个命令会安装所有交叉编译相关的包。在博主的电脑上，就需要安装以下包emerge -pv crossdev

These are the packages that would be merged, in order:

Calculating dependencies… done!
[ebuild N ] dev-util/unifdef-1.20 65 kB
[ebuild N ] sys-devel/crossdev-0.9.18-r10 0 kB

Total: 2 packages (2 new), Size of downloads: 65 kB

注意，crossdev只是一个工具，我们的最终目的是使用crossdev编译一个交叉工具链出来，有必要先看看帮助，直接运行crossdev命令
# crossdev Usage: crossdev [options] --target TARGET Options: --b, --binutils ver Specify version of binutils to use --g, --gcc ver Specify version of gcc to use --k, --kernel ver Specify version of kernel headers to use --l, --libc ver Specify version of libc to use -S, --stable Use latest stable versions as default -C, --clean target Uninstall specified target -P, --portage opts Options to pass to emerge (see emerge(1)) --with[out]-headers Build C library headers before C compiler? Stage Options: -s0, --stage0 Build just binutils -s1, --stage1 Also build a C compiler (no libc/C++) -s2, --stage2 Also build kernel headers -s3, --stage3 Also build the C library (no C++) -s4, --stage4 Also build a C++ compiler [default] Extra Fun (must be run after above stages): --ex-only Skip the stage steps above --ex-gcc Build extra gcc targets (gcj/ada/etc...) --ex-gdb Build a cross gdb --ex-insight Build a cross insight Target (-t) takes a tuple ARCH-VENDOR-OS-LIBC; see 'crossdev -t help'
上面可以看到，我们能用crossdev指定binutils gcc kernel和libc的版本，还有不同的编译stage来指定不同规模的工具链。甚至在Extra Fun中包含了gdb，扩展的gcc等支持，insight是gdb的图形化接口，博主没有用过，所以不知道。
再来看看crossdev支持的系统元组们
# crossdev -t help Supported Architectures: - alpha - arm / armeb - hppa (parisc) - ia64 - i386 / i486 / i586 / i686 (x86) - m68k - mips / mipsel / mips64 / mips64el - powerpc (ppc) / powerpc64 (ppc64) - sparc / sparc64 - s390 / s390x - sh / sh[1-5] / sh64 - x86_64 (amd64) Supported C Libraries: - glibc (gnu) - klibc [prob wont work] - newlib [bare metal/no operating system] - uclibc [not all arches are ported] Special Targets: - avr http://www.nongnu.org/avr-libc/ - bfin http://blackfin.uclinux.org/ - h8300 http://h8300-hms.sourceforge.net/ - mingw32 http://www.mingw.org/ - msp430 http://mspgcc.sourceforge.net/ - nios2 http://www.altera.com/products/ip/processors/nios2/ni2-index.html - xc16x http://www.infineon.com/ - ee / iop / dvp (ps2) [Playstation 2 targets] - ppu / spu (cell) [Cell/Playstation 3 targets] Softfloat toolchains: Include 'softfloat' in the 'vendor' field e.g. armeb-softfloat-linux-uclibc powerpc-booya_softfloat-linux-gnu
不懂的话您就看看上面关于系统元组的介绍，具体我就不解释了，好了，现在看是安装。开动拉。。。。。因为博主要安装mips64el-unknown-linux-gnu的编译器，就直接运行了
# crossdev --target mips64el-st-linux-gnu ------------------------------------------------------------------------------------------------------------------------------------------------------------- * Host Portage ARCH: x86 * Target Portage ARCH: mips * Target System: mips64el-st-linux-gnu * Stage: 4 (C/C++ compiler)

* binutils: binutils-[latest]
* gcc: gcc-[latest]
* headers: linux-headers-[latest]
* libc: glibc-[latest]

* PORTDIR_OVERLAY: /usr/local/portage/layman/gentoo-china
* PORT_LOGDIR: /var/log/portage
* PKGDIR: /usr/portage/packages/cross/mips64el-st-linux-gnu
* PORTAGE_TMPDIR: /var/tmp/cross/mips64el-st-linux-gnu
_ – ~ – _ – ~ – _ – ~ – _ – ~ – _ – ~ – _ – ~ – _ – ~ – _ – ~ – _ – ~ – _ – ~ – _ – ~ – _ – ~ – _ – ~ -
* Forcing the latest versions of {binutils,gcc}-config/gnuconfig … [ ok ]
* Log: /var/log/portage/cross-mips64el-st-linux-gnu-binutils.log
* Emerging cross-binutils …
这是个非常漫长的过程。。。。。。。。。因为是mips64el的，遇到了glibc checkfail的问题。这个问题正在解决中，以后再汇报。
下面假设你安装的是arm的
＃crossdev -t arm-unknown-linux-gnu

最后，再说说
mips64el-unknown-linux-gnu 和mips64el-st-linux-gnu。其实没有区别，你可以简单的理解为是谁制作了这个工具链，比如st就代表这个工具链是ST作的，比如，我曾经使用的一个mips64el-st-linux-gnu就是曾经从意法半导体的网站上下载的，不过现在好像链接已经没有了。而mips64el-unknown-linux-gnu是上面crossdev自己编译出来的，在gentoo的overlay中，使用的就是unknown，所以就沿用了unknown

你可以参考下面几个链接
http://www.gentoo.org/proj/en/base/embedded/handbook

http://psas.pdx.edu/GentooCrossCompilerHowto/

GCC初窥

erlv — Tue, 29 Dec 2009 12:44:03 +0000

这是gcc maillist中某国际友人 laurent@guerby.net 做的2个小时报告的ppt，报告题目为GCC Toulibre 20091216。最近一直想深入了解gcc，而这个ppt基本包含本博想了解的内容，所以将其翻译并分享到这里。翻译过程中，很多地方可能有错，请大家不吝赐教。原版的ppt见文末。

什么是GCC

GCC支持的语言

已经在代码树中：c(gcc),c++(g++),Java(gcj),Ada(GNAT),Objective-C(gobjc),Objective-C++(gobjc++),Fortran(gfortran),不在代码树中,但已经支持的Modula-2,Modula-3,Pascal(gpc),PL/1,D(gdc),Mercury,VHDL(ghdl).

GCC支持的目标平台

已经在代码树中的,可以在gcc-4.5/gcc/config子文件夹中找到,包括:alpha,arc,arm,avr,bfin,cris,crx,fr30,frv,h8300,i386,ia64,iq2000,lm32,m32c,m32r,m68hc11,m68k,mcore,mep,mips,mmix,mn10300,moxie,pa,pdp11,picochip,rs6000,rx,s390,score,sh,soft-fp,sparc,spu,stormy16,v850,vax,vms,xtensa
不在代码数中但已经支持的,可在GNU_Compiler_Collection的Wikipedia中找到,包括PDP-10和Z8000等14中终端.

gcc易编译

至少对于本地编译gcc,仅需以下几步
$ tar xfj gcc-4.4.2.tar.bz2 $ mkdir build && cd build $ ../gcc-4.4.2/configure –prefix=/opt/gcc $ make bootstrap && make install $ make -k check

gcc编译很快

具体速度依赖编译所用机器,在2×4个核的X86_64上仅需15分钟.在ARM Cortex A8@800Mhz上需要大约7小时.编译需要约512M内存.注意,对于开发版的GCC,因为需要很多内建的检测,所以编译会较慢.

自举

编译器是用程序语言编写并被编译成机器码以便执行的,所以使用特定编程语言写出的编译器是能够编译它自己的(译者注:写编译器的语言和编译器编译的语言要相同),这就是编译器的自举.GCC的自举过程为首先系统编译器编译生成stage1,而后stage1被用来编译它自己生成stage2.接着stage2被用来编译生成stage3,其中stage2和stage3生成的要完全相同.(译者注:现在一个简单的make命令，将自动完成make bootstrap)

编译前的准备工作.

目前多数发布的是4.3或4.4.在debian或者ubuntu上可以使用命令
$apt-get build-dep gcc
来得到编译环境.在windowss上也能通过Cygwin或Mingw得到

生成一个交叉编译器

生成一个交叉编译器更难,因为GCC,GNU libc和Linux内核都需要链接并依赖彼此的头文件和常量.另外你可能还需要代码树之外的补丁.推荐使用预编译好的工具链,如gcc-avr或者是Crosstool-ng之类的工具.

GCC项目历史

1985年Richard Stallman开始了GCC作为GNU C编译器的项目；
1991年GCC 1.x=>GCC 2.x;
1997年EGCS启动;
1999年EGCS成为官方GCC2.95,GCC引入委员会;
2001年GCC 3.x;
2005年GCC4.x,并6个月至1年发布一次.

贡献者

下面数据基于快速修改记录处理(quick ChangeLog parsing)生成.依次为:年份==修改记录===邮件数
1998 == 1685 == 107
1999 == 2629 == 196
2000 == 5588 == 326
2001 == 6356 == 355
2002 == 7259 == 371
2003 == 10440 == 443
2004 == 12857 == 440
2005 == 11657 == 407
2006 == 9221 == 356
2007 == 8611 == 366
2008 == 7789 == 357
2009 == 9028 == 341

基于GCC的有偿工作

有Redhat,Novell等系统集成商,AdaCore,CodeSourcery等开发工具提供商,IBM,AMD,Intel,ST半导体等芯片提供商,Google(15人为C++支持工作,15人为GCC架构工作),还有科研机构如INRIA Saclay等.

gcc是个相当大的项目

gcc-4.5-20091210/gcc除去测试集,使用SLOCCOUNT计数,并按语言分组(按比例从大到小):ANSI C:1067922(67.18%);Ada:485301(30.53%);asm:30379(1.91%);更多的统计数据如下:
31006 == 108 == asm
170569 == 62 == texi
189382 == 999 == ads
230459 == 714 == h
300237 == 229 == md
707707 == 871 == adb
1365750 == 772 == c
共识别3033097行

GCC中的选项

-O0=>无优化,和其他编译器有不同
-O1=>优化,但最小化编译时间
-O2=>有更多耗时的优化
-O3=>非常耗时的优化,如自动内联和向量化
-Os=>代码大小优化
怎样得到-O1具体的优化选项?
$gcc -Q --help=optimizers -O1
输出结果:
The following options control optimizations: -falign-jumps [disabled] -falign-labels [disabled] -falign-loops [enabled] ...
4.3约140个,4.4约160个,4.5约180。这样我们就能查看gcc中O0,O1,O2,O3,Os中所有相关的优化选项。
目标机相关的指令有哪些?运行命令
$ gcc -Q --target-help Target specific options: -m128bit-long-double sizeof(long double) is 16 -m32 Generate 32bit i386 code -m3dnow Support 3DNow! built-in functions -m64 Generate 64bit x86-64 code ....
此外还有一些选项,如
-march=…. => 选择一个指令集(注意,得到的可执行代码可能不能运行)
-mtune=… => 在指定的指令集中,针对某个目标机做优化(atom,core2,opteron等)
-native =>自动检测当前处理器

如何找到有趣的选项

在http://www.spec.org上找SPECint和SPECfp的详细结果,测量峰值时使用的选项都在文档中,或者使用自动调优工具,如Acovea, http://www.coyotegulch.com/products/acovea/

内建功能(Builtins)

gcc特用的,但一些其他编译器有提供的功能.这些功能很有趣,因为都是机器无关的.
例如:
int __builtin_ffs(unsigned int x)
返回1+x的最小指数(?),或者当x为0时返回0
还有一些机器相关的内联汇编,如asm(“fsinx %1,%0″:”=f” (result):”f”(angle));

GCC如何工作?

$ls -l /usr/bin/gcc-4.1 -rwxr-xr-x 1 root root 205952 2006-12-11 00:12 /usr/bin/gcc
可以看到,gcc程序很小,这仅仅是一个驱动器.它将根据命令行调用很多程序来完成任务.真正的编译器如下:
5.3M /usr/lib/gcc/x86_64-linux-gnu/4.1.2/cc1 5.8M/usr/lib/gcc/x86_64-linux-gnu/4.1.2/cc1plus 7.7M /usr/lib/gcc/x86_64-linux-gnu/4.1.2/gnat1 5.2M /usr/lib/gcc/x86_64-linux-gnu/4.1.2/jc1
因此真正的顺序是:gcc=>xx1=>as或ld.(译者注:请参见本文末尾的gcc -v helloworld.c)

Binutils是什么?

GCC指示一个文本文件到文本文件的转换器,Binutils做生成可执行机器码的工作.
运行命令
$gcc -S file.c
将只生成汇编文件file.s

GCC的内部架构

前端:每种编程语言有一个前端,包含该编程语言的词法分析，语法分析和语义分析，并将其翻译成统一的中间代码表示，接着该中间表示将会lower成GIMPLE。
中端:操作GIMPLE，依次做机器无关和机器相关的转换和优化。
后端:使用目标机器描述生成目标机器汇编文件。
RTL即寄存器转换语言。在优化时，可能需要对程序遍历数以百遍。

目标机器描述

这是一个模式匹配引擎，它描述每个机器指令的作用。它是一个包含分段C语言代码的文本文件。如gcc/config/i386/i386.md.机器描述的质量将影响最终生成的目标代码的质量。仅需对每个目标机创建一个描述，就能将所有的语言移植到该机器上。

关于Moxie

Moxie的博客 http://moxielogic.org/blog/。已有贡献，简化虚拟指令系统结构设计，为整个GNU工具链做贡献，现在已经可以运行Binutils，GCC，qemu和Linux。gcc/config/moxie/*.md有560行，gcc/config/moxie/*少于2000行。

中间代码形式

对于代码：
int f(int x, int y) { int tmp; tmp=x; if (x>0) tmp=-x; return tmp+y; }
$ gcc -S -O3 -fdump-tree-all t.c
得到共100多个文件。
例如t.c.003t.original内容如下：
f (int x, int y) { int D.2705; int tmp; tmp = x; if (x > 0) goto ; else goto ; : tmp = -x; : D.2705 = tmp + y; return D.2705; }
t.c.024t.ssa如下
f (int x, int y) { int tmp; int D.2705; : tmp_3 = x_2(D); if (x_2(D) > 0) goto ; else goto ; : tmp_4 = -x_2(D); : # tmp_1 = PHI D.2705_6 = tmp_1 + y_5(D); return D.2705_6; }

GCC与GDB

使用选项-g生成调试信息。在汇编文集中插入很多运行无关的代码,如DWARF(和ELF).GDB通过读入这些代码来映射运行中每个点的行号，内存你和寄存器。GCC甚至可以在优化时生产调试信息，但是所生成的信息将很难跟踪。

GCC和GDB中的bug

GCC可能产生错误的调试信息，GDB可能错误的读入调试信息，用户界面可能和GDB通信时出错，因此在实际中，需要在这几个项目中获得帮助来搞定bug，希望这些项目之间有更好的沟通。

GCC中的bug

GCC每次发布都伴随着数以百计的已知bug(其他的编译器也一样),GCC中紧急bug类型(bugzilla中的关键字):wrong-code,accepts-invalid,编译器内部出错时很容易找出、ice-on-valid、ice-on-invalid、wrong-debug、missed-optimization、rejects-valid、memory-hog、compile-time-hog、assemble-failure、build

如何报告GCC bug

链接：http://gcc.gnu.org/bugs 是个很好的必读资源，包含通常的非gcc bug。若真是bug，可以运行
$gcc -v -save-temps -O1 myfile.c
生成myfile.i文件，通常情况下，添加这两个附件并连同平台名称和编译器输出就足够了。出错和不出错的版本信息也很有帮助。

GCC4.5的新特性

在链接 http://gcc.gnu.org/gcc-4.5/changes.html中能找到，具体如下
第一，增加一个全新的链接时优化器(-flto),使用这一选项时，GCC能够为每个输入文件得到一个bytecode表示，并将它写入每个目标文件的特定ELF段中。当目标文件需要链接在一起时，所有的函数体将从这些ELF段中读出，并将其作为转换单元的一部分表示。这将使得过程间优化能在不同的文件间进行(甚至不同的语言间),为生成代码的性能提升提供可能。为使用链接时优化器，-flto选项需要在编译时和最终链接过程中指定，若程序不需要任何符号输出，将-flto和-fwhopr以及-fwhole-program一起使用可以让过程间优化器使用更激进的假设进而提升性能；第二，自动并行化可以作为Graphite的一部分打开，在打开-ftree-parallelize-loops=的同时，指定-floop-parallelize-all可以打开基于Graphite的优化；第三，现在可以在不修改源码的前提下扩展编译器。新加入的选项-fplugin=file.so告诉编译器载入共享目标文件file.so，并将它作为编译器的一部分运行。内部的文档描述了插件和编译器之间交互的细节以及如何交互。见 http://gcc.gnu.org/wiki/GCC_PluginAPI

如何提问和贡献

http://gcc.gnu.org/ 有详细的用户手册。gcc-help@gcc.gnu.org 是gcc帮助用的邮件列表
IRC用户帮助 => irc.freenode.org #gcc
http://gcc.gnu.org/ml =>邮件列表归档
gcc-patches@gcc.gnu.org 补丁
gcc@gcc.gnu.org
gcc-testresults@gcc.gnu.org
IRC开发频道 => irc.oftc.net #gcc

GCC外的其他编译器

自由的:LLVM和Open64，有插件时变得很有趣。
非自由的:ICC（Intel),XLC(IBM)…
评测编译器很难，最好基于你自己的代码，做自己的设置。当心bug和技术支持。如果你想做多平台，那GCC是很难搞定的。

GCC编译农场(GCC Compile Farm)

链接 http://gcc.gnu.org/wiki/CompileFarm。目的:为自由软件开发者提供方便访问且多样的体系结构用来编译和测试(并不局限于GCC).由FSF法国提供支持。很多研究所，个人和公司提供机器，主机和帮助。AMD和Genesi贡献了机器。

结论

GCC是一个庞大的老项目，但是它依旧活力十足，并有很多公司提供支持。学习GCC非常艰巨。即便高质量到Bug报告也是对GCC的贡献。

Gcc Toulibre 20091216

View more documents from erlv.

附：在译者电脑上运行gcc -v helloworld.c的输出。
$ gcc -v helloworld.c Using built-in specs. Target: i686-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.4.2/work/gcc-4.4.2/configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.4.2 --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/include --datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.2 --mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.2/man --infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.4.2/info --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/include/g++-v4 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.4.2/python --disable-libgcj --with-arch=i686 --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.2 p1.0' Thread model: posix gcc version 4.4.2 (Gentoo 4.4.2 p1.0) COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686' /usr/libexec/gcc/i686-pc-linux-gnu/4.4.2/cc1 -quiet -v helloworld.c -D_FORTIFY_SOURCE=2 -quiet -dumpbase helloworld.c -mtune=generic -march=i686 -auxbase helloworld -version -o /tmp/ccRoxwan.s ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/include /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/include-fixed /usr/include End of search list. GNU C (Gentoo 4.4.2 p1.0) version 4.4.2 (i686-pc-linux-gnu) compiled by GNU C version 4.4.2, GMP version 4.3.1, MPFR version 2.4.1-p1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: bfddefec40932d7559ac2c097447ec05 COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686' /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../../i686-pc-linux-gnu/bin/as -V -Qy -o /tmp/cc0ViYlD.o /tmp/ccRoxwan.s GNU assembler version 2.18 (i686-pc-linux-gnu) using BFD version (GNU Binutils) 2.18 COMPILER_PATH=/usr/libexec/gcc/i686-pc-linux-gnu/4.4.2/:/usr/libexec/gcc/i686-pc-linux-gnu/4.4.2/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/libexec/gcc/i686-pc-linux-gnu/4.4.2/:/usr/libexec/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../../i686-pc-linux-gnu/bin/ LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../../i686-pc-linux-gnu/lib/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686' /usr/libexec/gcc/i686-pc-linux-gnu/4.4.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../crt1.o /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/crtbegin.o -L/usr/lib/gcc/i686-pc-linux-gnu/4.4.2 -L/usr/lib/gcc/i686-pc-linux-gnu/4.4.2 -L/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../.. /tmp/cc0ViYlD.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/crtend.o /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../crtn.o

您可能也喜欢：
webkit-龙小组成立	zzMozilla的疯狂构想 Firefox 4将开拓浏览器新疆界	龙芯N32系统上的Squirrelfish性能	JIT Compiler and Virtual Machine SW Engineer for Web Browsers in Qualcomm	擦亮眼睛 “百度Hi”用户协议有猫腻
无觅

编译点滴 » elf

前瞻-全时优化和LLVM-2

LLVM的架构设计：

总览

编译时：外部前端和静态优化

连接时和过程间优化

离线和实时代码生成器

运行时程序行为采集和重优化

用户行为信息制导的离线重优化

LLVM的评测和应用

评测LLVM

LLVM的应用

与LLVM相关的工作:

相关文章：

来仔细看看GCC 4.5.0

总体说明：

改进：

新语言支持和特定语言改进

其他改进：

相关文章：

GNU工具链学习笔记

相关文章：

WebKit和Firefox的JavaScript性能对比

相关文章：

GCC中的pie和fpie选项

相关文章：

Strace命令介绍

相关文章：

Gentoo中的交叉编译利器–crossdev

相关文章：

GCC初窥

相关文章：