GCC编译背后(第二部分：汇编和链接)-lwchsz-ChinaUnix博客

-m elf_i386

这里指定不同平台上的链接脚本，可以通过--verbose命令查看脚本的具体内容，如ld -m elf_i386 --verbose，它实际上被存放在一个文件中(/usr/lib/ldscripts目录下），你可以去修改这个脚本，具体如何做？请参考ld的手册。在后面我们将简要提到链接脚本中是如何预定义变量的，以及这些预定义变量如何在我们的程序中使用。需要提到的是，如果不是交叉编译，那么无须指定该选项。

-dynamic-linker /lib/ld-linux.so.2

指定动态装载器/链接器，即程序中的INTERP段中的内容。动态装载器/连接器负责连接有可共享库的可执行文件的装载和动态符号连接。

-o test

指定输出文件，即可执行文件名的名字

/usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc/i486-slackware-linux/4.1.2/crtbegin.o

链接到test文件开头的一些内容，这里实际上就包含了.init等节区。.init节区包含一些可执行代码，在main函数之前被调用，以便进行一些初始化操作，在C++中完成构造函数功能，更多细节请参考资料[9]

test.o myprintf.o

链接我们自己的可重定位文件

-L/usr/lib/gcc/i486-slackware-linux/4.1.2 -L/usr/i486-slackware-linux/lib -L/usr/lib/ -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed

链接libgcc库和libc库，后者定义有我们需要的puts函数

/usr/lib/gcc/i486-slackware-linux/4.1.2/crtend.o /usr/lib/crtn.o

链接到test文件末尾的一些内容，这里实际上包含了.fini等节区。.fini节区包含了一些可执行代码，在程序退出时被执行，作一些清理工作，在C++中完成析构造函数功能。我们往往可以通过atexit来注册那些需要在程序退出时才执行的函数。

对于crtbegin.o和crtend.o这两个文件，貌似完全是用来支持C++的构造和析构工作的[9]，所以可以不链接到我们的可执行文件中，链接时把它们去掉看看，

Quote:

$ ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test /usr/lib/crt1.o /usr/lib/crti.o test.o myprintf.o -L/usr/lib -lc /usr/lib/crtn.o    #后面发现不用链接libgcc，也不用--eh-frame-hdr参数
$ readelf -l test

Elf file type is EXEC (Executable file)
Entry point 0x80482b0
There are 7 program headers, starting at offset 52

Program Headers:
Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz Flg Align
PHDR           0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
INTERP         0x000114 0x08048114 0x08048114 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]
LOAD           0x000000 0x08048000 0x08048000 0x003ea 0x003ea R E 0x1000
LOAD           0x0003ec 0x080493ec 0x080493ec 0x000e8 0x000e8 RW 0x1000
DYNAMIC        0x0003ec 0x080493ec 0x080493ec 0x000c8 0x000c8 RW 0x4
NOTE           0x000128 0x08048128 0x08048128 0x00020 0x00020 R   0x4
GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4

Section to Segment mapping:
Segment Sections...
   00
   01     .interp
   02     .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata
   03     .dynamic .got .got.plt .data
   04     .dynamic
   05     .note.ABI-tag
   06
$ ./test
hello, world!

完全可以工作，而且发现.ctors(保存着程序中全局构造函数的指针数组), .dtors（保存着程序中全局析构函数的指针数组）,.jcr（未知）,.eh_frame节区都没有了，所以crtbegin.o和crtend.o应该包含了这些节区。
而对于另外两个文件crti.o和crtn.o，通过readelf -S查看后发现它们都有.init和.fini节区，如果我们不需要让程序进行一些初始化和清理工作呢？是不是就可以不链接这个两个文件？试试看。

Quote:

$ ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test /usr/lib/crt1.o test.o myprintf.o -L/usr/lib/ -lc
/usr/lib/libc_nonshared.a(elf-init.oS): In function `__libc_csu_init':
(.text+0x25): undefined reference to `_init'

貌似不行，竟然有人调用了__libc_csu_init函数，而这个函数引用了_init。这两个符号都在哪里呢？

Quote:

$ readelf -s /usr/lib/crt1.o | grep __libc_csu_init
18: 00000000 0 NOTYPE GLOBAL DEFAULT UND __libc_csu_init
$ readelf -s /usr/lib/crti.o | grep _init
17: 00000000 0 FUNC GLOBAL DEFAULT 5 _init

竟然是crt1.o调用了__libc_csu_init函数，而该函数却引用了我们没有链接的crti.o文件中定义的_init符号。这样的话不链接 crti.o和crtn.o文件就不成了罗？不对吧，要不干脆不用crt1.o算了，看看gcc额外连接进去的最后一个文件crt1.o到底干了个啥子？

Quote:

$ ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test test.o myprintf.o -L/usr/lib/ -lc
ld: warning: cannot find entry symbol _start; defaulting to 00000000080481a4

这样却说没有找到入口符号_start，难道crt1.o中定义了这个符号？不过它给默认设置了一个地址，只是个警告，说明test已经生成，不管怎样先运行看看再说。

Quote:

$ ./test
hello, world!
Segmentation fault

貌似程序运行完了，不过结束时冒出个段错误？可能是程序结束时有问题，用gdb调试看看：

Quote:

$ gcc -g -c test.c myprintf.c    #产生目标代码, 非交叉编译，不指定-m也可以链接成功，所以下面可以去掉-m参数
$ ld -dynamic-linker /lib/ld-linux.so.2 -o test test.o myprintf.o -L/usr/lib -lc
ld: warning: cannot find entry symbol _start; defaulting to 00000000080481d8
$ ./test
hello, world!
Segmentation fault
$ gdb ./test
...
(gdb) l
1       #include "test.h"
2
3       int main()
4       {
5               myprintf();
6               return 0;
7       }
(gdb) break 7            #在程序的末尾设置一个断点
Breakpoint 1 at 0x80481bf: file test.c, line 7.
(gdb) r                    #程序都快结束了都没问题，怎么会到最后出个问题呢？
Starting program: /mnt/hda8/Temp/c/program/test
hello, world!

Breakpoint 1, main () at test.c:7
7       }
(gdb) n                    #单步执行看看，怎么下面一条指令是0x00000001，肯定是程序退出以后出了问题
0x00000001 in ?? ()
(gdb) n                    #诶，当然找不到边了，都跑到0x00000001了
Cannot find bounds of current function
(gdb) c                    #原来是这么回事，估计是return 0返回之后出问题了，看看它的汇编去。
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0x00000001 in ?? ()
$ gcc -S test.c #产生汇编代码
$ cat test.s    #后面就这么几条指令，难不成ret返回有问题，不让它ret返回，把return改成_exit直接进入内核退出
...
        call    myprintf
        movl    $0, %eax
        addl    $4, %esp
        popl    %ecx
        popl    %ebp
        leal    -4(%ecx), %esp
        ret
...
$ vim test.c
$ cat test.c    #就把return语句修改成_exit了。
#include "test.h"
#include /* _exit */

int main()
{
        myprintf();
        _exit(0);
}
$ gcc -g -c test.c myprintf.c
$ ld -dynamic-linker /lib/ld-linux.so.2 -o test test.o myprintf.o -L/usr/lib -lc
ld: warning: cannot find entry symbol _start; defaulting to 00000000080481d8
$ ./test    #竟然好了，再看看汇编有什么不同
hello, world!
$ gcc -S test.c
$ cat test.s    #貌似就把ret指令替换成了_exit函数调用，直接进入内核，然内核让处理了，那为什么ret有问题呢？
...
        call    myprintf
        subl    $12, %esp
        pushl   $0
        call    _exit
...
$ gdb ./test    #把代码改回去（改成return 0;），再调试看看调用main函数返回时的下一条指令地址eip
...
(gdb) l
warning: Source file is more recent than executable.
1       #include "test.h"
2
3       int main()
4       {
5               myprintf();
6               return 0;
7       }
(gdb) break 5
Breakpoint 1 at 0x80481b5: file test.c, line 5.
(gdb) break 7
Breakpoint 2 at 0x80481bc: file test.c, line 7.
(gdb) r
Starting program: /mnt/hda8/Temp/c/program/test

Breakpoint 1, main () at test.c:5
5               myprintf();
(gdb) x/8x $esp    #发现0x00000001刚好是之前我们调试时看到的程序返回后的位置，即eip，说明程序在初始化的时候
                #这个eip就是错误的。为什么呢？因为我们根本没有链接进来初始化的代码，而是在编译器自己给我们
                #初始化了一个程序入口即00000000080481d8，也就是说，没有任何人调用main,main不知道返回哪里去
                #所以，我们直接让main结束时进入内核调用_exit而退出则不会有问题
0xbf929510:     0xbf92953c      0x080481a4      0x00000000      0xb7eea84f
0xbf929520:     0xbf92953c      0xbf929534      0x00000000      0x00000001

通过上面的演示和解释发现只要把return语句修改为_exit语句，程序即使不链接任何额外的目标代码都可以正常运行（原因是不连接那些额外的文件时相当于没有进行初始化操作，如果在程序的最后执行ret汇编指令，程序将无法获得正确的eip，从而无法进行后续的动作）。但是为什么会有“找不到 _start符号”的警告呢？通过readelf -s查看crt1.o发现里头有这个符号，并且crt1.o引用了main这个符号，是不是意味着会从_start进入main呢？是不是程序入口是 _start，而并非main呢？

先来看看刚才提到的链接器的默认链接脚本(ld -m elf_386 --verbose)，它告诉我们程序的入口(entry)是_start，而一个可执行文件必须有一个入口地址才能运行，所以这就是说明了为什么ld一定要提示我们“_start找不到”，找不到以后就给默认设置了一个地址。

Quote:

$ ld --verbose | grep ^ENTRY #非交叉编译，可不用-m参数；ld默认找_start入口，并不是main哦！
ENTRY(_start)

原来是这样，程序的入口(entry)竟然不是main函数，而是_start。那干脆把汇编里头的main给改掉算了，看行不行？

Quote:

$ cat test.c
#include "test.h"
#include      /* _exit */

int main()
{
        myprintf();
        _exit(0);
}
$ gcc -S test.c
$ sed -i -e "s#main#_start#g" test.s    #把汇编中的main全部修改为_start，即修改程序入口为_start
$ gcc -c test.s myprintf.c
$ ld -dynamic-linker /lib/ld-linux.so.2 -o test test.o myprintf.o -L/usr/lib/ -lc    #果然没问题了 :-)
$ ./test
hello, world!

_start竟然是真正的程序入口，那在有main的情况下呢？为什么在_start之后能够找到main呢？这个看看alert7大叔的"Before main分析"[5]吧，这里不再深入介绍。总之呢，通过修改程序的return语句为_exit(0)和修改程序的入口为_start，我们的代码不链接gcc默认链接的那些额外的文件同样可以工作得很好。并且打破了一个学习C语言以来的常识：main函数作为程序的主函数，是程序的入口，实际上则不然。

再补充一点内容，在ld的链接脚本中，有一个特别的关键字PROVIDE，由这个关键字定义的符号是ld的预定义字符，我们可以在C语言函数中扩展它们后直接使用。这些特别的符号可以通过下面的方法获取，

Quote:

$ ld --verbose | grep PROVIDE | grep -v HIDDEN
PROVIDE (__executable_start = 0x08048000); . = 0x08048000 + SIZEOF_HEADERS;
PROVIDE (__etext = .);
PROVIDE (_etext = .);
PROVIDE (etext = .);
_edata = .; PROVIDE (edata = .);
_end = .; PROVIDE (end = .);

这里面有几个我们比较关心的，第一个是程序的入口地址__executable_start，另外三个是etext，edata，end，分别对应程序的代码段(text)、初始化数据(data)和未初始化的数据(bss)（可以参考资料[6]和man etext），如何引用这些变量呢？看看这个例子。

Code:

[Ctrl+A Select All]

到这里，程序链接过程的一些细节都介绍得差不多了。在《动态符号链接的细节》中将主要介绍ELF文件的动态符号链接过程。

本节参考资料

[1] An beginners guide to compiling programs under Linux.

[2] gcc manual

[3] A Quick Tour of Compiling, Linking, Loading, and Handling Libraries on Unix

[4] Unix 目标文件初探
http://www.ibm.com/developerworks/cn/aix/library/au-unixtools.html
[5] Before main()分析
http://www.xfocus.net/articles/200109/269.html
[6] A Process Viewing Its Own /proc//map Information