linux arm运行x86_arm版本的ubuntu系统

Linux X86 程序启动 – main函数是如何被执行的 　　一、目标读者二、覆盖范围三、调用过程分析3.1 main函数的调用main函数如何被调用 　　3.2 _start函数分析3.2.1 首先，_start是如何启动的？3.2.2 _start函数就是我们开始的地方3.2.3 调用__libc_start_main之前的设置3.2.4 环境变量哪里去了？ 　　3.3 __libc_start_main函数分析3.3.1 __libc_start_main功能概述3.3.2 调用init参数 　　3.4 __libc_csu_init函数分析3.4.1 用户应用程序的构造函数3.4.2 这个函数到底是干什么的？3.4.3 但是__libc_csu_init里的循环是干什么的？ 　　3.5 _init函数分析3.5.1 init函数的调用3.5.2 _init函数起始于常规的C函数调用 　　3.6 gmon_start函数分析生成profile文件 　　3.7 frame_dummy函数分析函数并不是空的 　　3.8 _do_global_ctors_aux函数分析3.8.1 终于到构造函数了！3.8.2 来看个例子3.8.3 prog2的_init函数，像极了prog1的3.8.4 这是将要调用的函数的源代码3.8.5 汇编语言也是这样3.8.6 函数开始的部分3.8.7 循环之前的设置3.8.8 此时执行到了loop的顶端3.8.9 函数谢幕3.8.10 承诺过你的使用debugger进入prog2 　　3.9 回到__libc_csu_init__3.10 这是另一个函数的循环调用3.11 程序将返回__libc_start_main__exit()函数运行了更多的循环 　　四、这个程序，把上面所有的过程联系了起来五、结尾六、参考阅读 　　译者注： 本文是我在理解可执行文件代码段时，从网上搜索到的一篇文章，文章详细介绍了X86系统main函数调用前后的一些细节，并阐述了C程序的构造函数和析构函数，以及 .init,.fini,init_array和fini_array各section相对于main函数及彼此的执行顺序。遗憾的是这篇文章是基于32位CPU架构来研究的，而本博客的文章是以64位CPU架构来研究的。如果有时间我会顺着相同的思路在64位机器上将该过程整理出来。其实两者仅在汇编语言传参方式和位置无关码的生成方式上略有区别，所以这篇文章还是有很大借鉴意义的。 　　原文链接：http://dbp-consulting.com/tutorials/debugging/linuxProgramStartup.html 　　一、目标读者 　　这篇文章主要面向对象是为了那些想深入了解linux下程序的加载过程的读者，它主要介绍了X86 ELF文件的动态加载过程。这篇文章将会使你理解如何debug main函数启动前发生的问题。本文基于事实描述，但是将会忽略一些与上述主题无关的细节。如果你是静态编译的，一些细节将会与本文的描述不符，这篇文章并不会列举出这些差异。当你读完这篇文章，你将会对X86的main函数启动前后非常了解。 　　二、覆盖范围 　　

　　当你读完，你将会理解上图。 　　三、调用过程分析 　　3.1 main函数的调用 　　main函数如何被调用 　　我们将编译一个最简单的C程序——空的main函数，然后，查看其反汇编代码以理解程序是如何从启动开始调用到main函数。从反汇编代码中，我们发现程序是由一个_start函数最终调用main函数执行的。 　　将上述代码保存为prog1.c，首先要做的是使用下面的命令编译这个文件： 　　我们首先查看其反汇编代码，通过这个程序来查看关于程序启动的一些过程，然后再用GDB去调试比这个版本稍微复杂一点的程序prog2。下面将会列举objdump -d prog1的输出，但是并不会按照该命令原本的顺序列举，而是会按照输出内容执行的顺序来输出（你可以自己dump这个结果，比如使用命令objdump -d prog1 > prog1.dump，就能保存objdump的输出，然后使用你熟悉的编辑器打开并查看它）。（但是RPUVI——一个真正的程序员是使用VI的）。 　　3.2 _start函数分析 　　3.2.1 首先，_start是如何启动的？ 　　当你执行一个程序的时候，shell或者GUI会调用execve()，它会执行linux系统调用execve()。如果你想了解关于execve()函数，你可以简单的在shell中输入man execve。这些帮助来自于man手册（包含了所有系统调用）的第二节。简而言之，系统会为你设置栈，并且将argc，argv和envp压入栈中。文件描述符0，1和2（stdin, stdout和stderr）保留shell之前的设置。加载器会帮你完成重定位，调用你设置的预初始化函数。当所有搞定之后，控制权会传递给_start()，下面是使用objdump -d prog1输出的_start函数的内容： 　　3.2.2 _start函数就是我们开始的地方 　　任何值xor自身得到的结果都是0。所以xor %ebp,%ebp语句会把%ebp设置为0。ABI（Application Binary Interface specification）推荐这么做，目的是为了标记最外层函数的页帧（frame）。接下来，从栈中弹出栈顶的值保存到%esi。在最开始的时候我们把argc，argv和envp放到了栈里，所以现在的pop语句会把argc放到%esi中。这里只是临时保存一下，稍后我们会把它再次压回栈中。因为我们弹出了argc，所以%ebp现在指向的是argv。mov指令把argv放到了%ecx中，但是并没有移动栈指针。然后，将栈指针和一个可以清除后四位的掩码做and操作。根据当前栈指针的位置不同，栈指针将会向下移动0到15个字节。这么做，保证了任何情况下，栈指针都是16字节的偶数倍对齐的。对齐的目的是保证栈上所有的变量都能够被内存和cache快速的访问。要求这么做的是SSE，就是指令都能在单精度浮点数组上工作的那个（扩展指令集）。比如，某次运行时，_start函数刚被调用的时候，%esp处于0xbffff770。在我们从栈上弹出argc后，%esp指向0xbffff774。它向高地址移动了（往栈里存放数据，栈指针地址向下增长；从栈中取出数据，栈指针地址向上增长）。当对栈指针执行了and操作后，栈指针回到了0xbffff770。 　　3.2.3 调用__libc_start_main之前的设置 　　现在，我们把__libc_start_main函数的参数压入栈中。第一个参数%eax被压入栈中，里面保存了无效信息，原因是稍后会有七个参数将被压入栈中，但是为了保证16字节对齐，所以需要第八个参数。这个值也并不会被用到。__libc_start_main是在链接的时候从glibc复制过来的。在glibc的代码中，它位于csu/libc-start.c文件里。__libc_start_main的定义如下： 　　所以，我们期望_start函数能够将__libc_start_main需要的参数按照逆序压入栈中。值__libc_start_main参数内容%eax未知不关心%espvoid (*stack_end)已被对齐的栈指针%edxvoid (*rtld_fini)(void)加载器传到edx中的动态链接器的析构函数。被__libc_start_main函数通过__cxat_exit()注册，为我们已经加载的动态库调用FINI section0xvoid (*fini)(void)__libc_csu_fini——程序的析构函数。被__libc_start_main 通过 __cxat_exit()注册0x80483a0void (*init)(void)__libc_csu_init——程序的构造函数。于main函数之前被__libc_start_main函数调用%ecxchar ubp_avargv相对栈的偏移值%esiarcgargc相对栈的偏移值0xint(*main)(int, char, char)我们程序的main函数，被__libc_start_main函数调用main函数的返回值被传递给exit()函数，用于终结我们的程序 　　调用__libc_start_main函数前，栈的内容 　　__libc_csu_fini函数也是从glibc被链接进我们代码的，它的源代码位于csu/elf-init.c中。稍后我们会看到它。 　　3.2.4 环境变量哪里去了？ 　　你是否注意到我们并没有envp（栈里指向我们环境变量的指针）？它并不是__libc_start_main函数的参数。但是我们知道main函数的原型其实是int main(int argc, char argv, char envp)。所以，到底怎么回事？ 　　其实，__libc_start_main函数会调用__libc_init_first，这个函数会使用内部信息去找到环境变量（实际上环境变量就位于argv的终止字符null的后面），然后设置一个全局变量__environ，这个全局变量可以被__libc_start_main函数内部任何地方使用，包括调用main函数时。当envp建立了之后，__libc_start_main函数会使用相同的小技巧，越过envp数组之后的NULL字符，另一个向量——ELF辅助向量（加载器使用它给进程传递一些信息）。通过一个简单的方法可以查看里面的内容：运行程序前，设置环境变量LD_SHOW_AUXV=1。这是对于prog1运行的结果。 　　有趣吧？各种各样的信息。AT_ENTRY是_start的地址，还有我们的UID、有效UID和GID。而且，可以看出来我们的电脑是i686，times()的频率是100（每秒的clock-ticks数？稍后我调查一下）。AT_PHDR是ELF program header 的位置，它包括了程序中所有segment在内存中的位置信息，重定位条目和加载器需要的一些信息。AT_PHENT是header entry的字节数。接下来我们就不再顺着这个思路研究下去了，因为我们并不需要这些信息。 　　3.3 __libc_start_main函数分析 　　3.3.1 __libc_start_main功能概述 　　稍后本文会详细介绍__libc_start_main函数，但是，它的主要功能如下：处理关于setuid、setgid程序的安全问题启动线程注册用户程序的fini和rtld_fini参数，然后被at_exit调用，从而完成用户程序和加载器的负责清理工作的函数调用其init参数调用main函数，并把argc和argv参数、环境变量传递给它调用exit函数，并将main函数的返回值传递给它 　　3.3.2 调用init参数 　　__libc_start_main函数的init参数被设置成了__libc_csu_init函数，它也是被链接进我们代码的。它来源于glibc源代码中的csu/elf-init.c。其C代码如下（原代码只不过多了一些#ifdef）： 　　3.4 __libc_csu_init函数分析 　　3.4.1 用户应用程序的构造函数 　　__libc_csu_init函数相当重要，因为它是我们可执行程序的构造函数。“等等！，我们的程序不是C++程序啊！”。是的，不是C++程序，但是构造函数和析构函数的概念并非属于C++，因为它的诞生早于C++。对于任意的可执行程序都可以有一个C函数的构造函数__libc_csu_init和C函数的析构函数__libc_csu_fini。在构造函数内部，你将会看到，可执行程序会找到全局C函数组成的构造函数集，并且调用它们。任何一个C程序都是可以有的构造函数集的。稍后，我会展示一下。如果你觉得别扭，你可以将它们称为Initializers和Finalizers。下面是__libc_csu_init函数的反汇编代码： 　　3.4.2 这个函数到底是干什么的？ 　　再这我们先不多说了，但是我觉得你还挺想知道的。get_pc_truck函数有点有趣。它是给位置无关码使用的。设置它们可以让位置无关码正常工作。为了让它们工作，基址寄存器（%ebp）需要知道GLOBAL_OFFSET_TABLE。其部分代码如下： 　　好，我们仔细看看发生了什么。调用__get_pc_thunk_bx时，像所有其他函数调用一样，将下一条指令的地址压入栈中。这样，当函数返回时，就会继续执行下条指令。这个地址就是我们需要的地址。所以，在__get_pc_thunk_bx中，我们将返回地址从栈中复制到%ebx中。当返回的时候，下条指令会把_GLOBAL_OFFSET_TABLE_加到%ebx上去，其中_GLOBAL_OFFSET_TABLE_代表了当前地址和位置无关码使用的GOT(global offset table)的差值。在GOT中保存了我们想访问的变量的指针的集合，并且我们只需要知道数据在这个表中的偏移量就行。加载器会为我们修改这个表里面的地址。对于函数来讲，也有一个类似的表（PLT）。汇编里面这么编写实在是太烦人了，但是，在C或者C++中，你可以将-pic参数传递给编译器，它将会自动帮你完成这个工作。如果有兴趣的话可以看看编译器的源码，你就知道编译器如何使用-pic这个标志去编译源码了。 　　译者注：上述·get_pc_truck·函数的主要目的其实是变量对应的GOT，以通过它变量真正的值。之所以这么写，是因为在32位系统里，没有类似于rip的寄存器，因此并不能直接当前指令的地址，而在64位系统里就不用这种小技巧了。详细请参考参考阅读[1]. 　　3.4.3 但是__libc_csu_init里的循环是干什么的？ 　　等我们讨论完init()（实际上调用的是_init）之后，我们将会讨论__libc_csu_init函数里的循环。现在我们只要记住：它调用了用户程序中所有用C代码编写的initializers. 　　3.5 _init函数分析 　　3.5.1 init函数的调用 　　好的，当加载器将控制权交给_start函数之后，_start函数将会调用__libc_start_main函数，__libc_start_main函数会调用__libc_csu_init函数, __libc_csu_init函数会调用_init函数。 　　3.5.2 _init函数起始于常规的C函数调用 　　如果你想了解C函数调用规范的话，请参考这篇博客Basic Assembler Debugging with GDB。简单来讲就是，调用者的基址寄存器（%ebp）会被保存到栈里，当前函数的基址寄存器（%ebp）会指向栈顶，然后，保留4个字节空间。这里有趣的是第一次函数调用。它的作用和我们之前看到的之前调用get_pc_trunk非常像。如果你仔细看的话，发现调用的是下一条指令的地址！这就好像仅仅是顺序执行了而已，但是这么做的目的是，当前的地址被压入了栈中。然后通过弹出栈操作，又把它放到了%ebx中，之后就可以用它来设置访问全局访问表了。 　　3.6 gmon_start函数分析 　　生成profile文件 　　然后，我们来看gmon_start函数。如果它是空的，我们跳过它，不调用它。否则，调用它来设置profiling。该函数调用一个例程开始profiling，并且调用at_exit去调用另一个程序运行,并且在运行结束的时候生成gmon.out。 　　译者注： 为了优化软件中频繁调用的部分，从而提高程序整体执行的效率，我们可以在使用gcc编译的时候加上 -pg标志。这样在程序运行结束的时候会生成一个记录程序运行状态的文件叫做gmon.out。然后，我们可以使用一个名为gprof的GNU profiler工具来分析该文件从而获得程序各部分的运行时间，来反映其运行性能。详情请参考参考阅读[2]. 　　3.7 frame_dummy函数分析 　　函数并不是空的 　　完成上述两者之一的某个函数之后，接下来frame_dummy函数会被调用。其目的是调用__register_frame_info函数，但是，调用frame_dummy是为了给上述函数设置参数。这么做的目的是为了在出错处理是设置unwinding stack frames。这个非常有意思，但是并不是这次讨论的主题，所以以后有机会我们再讨论它。 　　3.8 _do_global_ctors_aux函数分析 　　3.8.1 终于到构造函数了！ 　　终于调用到_do_global_ctors_aux函数了。如果在调用main函数之前，你的程序出了问题，你很可能需要看看这个函数。当然，这里存放了全局C++对象的构造函数，但是，这里也能存放其他东西。 　　3.8.2 来看个例子 　　我们修改程序prog1，并把它叫做prog2。令人兴奋的部分是__attribute__ ((constructor))，它告诉GCC：链接器应该在__do_global_ctors_aux使用的表里创建一个指针指向这里。如你所见，我们编写的构造函数确实beido（__FUNCTION__被编译器替换成了当前函数的名字，这就是GCC魅力所在）。 　　3.8.3 prog2的_init函数，像极了prog1的 　　稍后我们将使用GDB看看到底发生了什么。我们将进入prog2的_init函数。 　　我们可以看到，上述的地址和prog1的地址略微有所不同。这些有差异的地址似乎相对于prog1移动了28个字节。这里，有两个函数：”a_constructor”（加上结束符一共14个字节）、”main”（加上结束符一共5个字节）和两个格式化字符串”%s\n”（2*4个字节，加上一个1字节的换行符和终止符），所以14 + 5 + 4 + 4 = 27？ 似乎还差一个。不管怎样，这只是个猜想，我就不仔细研究了。然后我们就要跳入到__do_global_ctors_aux函数中去，看看到底发生了什么。 　　3.8.4 这是将要调用的函数的源代码 　　为了方便研究，我们列举出__do_global_ctors_aux函数的C代码，它位于GCC源码中的gcc/crtstuff.c里。 　　如上所示，p的值被初始化成__CTOR_END__减去一个字节。这是一种指针算法，如果指针指向一个函数，在这种情况下，-1表示向上移动一个指针或者说4个字节。我们也能从汇编里面看出来。当指针不等于-1时，调用这个指针指向的函数，并且再次将指针上移。很明显，这个指针数组起始于-1，并且包含若干个函数指针。 　　3.8.5 汇编语言也是这样 　　下面是使用objdump -d得到的__do_global_ctors_aux函数对应的汇编语言。我们将仔细的查看它的每条指令，以便你就能够在我们使用debugger之前完全了解它。 　　3.8.6 函数开始的部分 　　函数最开始的部分依然遵从了C函数正常的调用惯例（保存调用者的栈基址寄存器，设置当前函数的栈基址寄存器），本函数中还增加了一点：额外把%ebx保存到了栈中，因为这个函数后面会使用到它。同时，我们也为（C代码中的）指针p保留了空间。你可能注意到了，即使我们在栈上为其开辟了空间，但是从未使用这部分空间。取而代之的是，p将会保存到%ebx中，*p会保存到%eax中。 　　3.8.7 循环之前的设置 　　看起来编译器做了一些优化，编译器并没有直接“加载__CTOR_END__，然后将其值减去1，再查找它指向的内容”，而是直接加载*(__CTOR_END__ – 1)，这是一个立即数0x8049f14（注意，$0x8049f14意思是一个立即数，而不带$，只写0x8049f14的意思是这个地址指向的内容）。这个数里面的内容被直接放到了%eax中，然后立刻比较%eax和-1，如果相等，则跳转到地址0x，回收栈，弹出我们保存在栈里的内容，函数调用结束，返回。 　　假设在函数表中至少有一个值，立即数0x8049f14被存放到%ebx，也就是函数指针p，然后执行指令xchg %ax,%ax，这是什么鬼？原来这是X86 16或者32位里的一个nop（No Operation）语句。它什么也不做，只是占据了一个指令周期，起一个占位符作用而已。在这种情况下，使循环开始于，而不是。这么做的好处是使循环开始的地方以4字节对齐，这样整个循环将会极大可能的被保存到一个cache line里，而不会被分成两段，从而起到加速执行的作用。 　　3.8.8 此时执行到了loop的顶端 　　接下来，将%ebx减去4，从而为下一次循环做好准备，调用%eax里保存的地址对应的函数，然后将下一个函数指针移至%eax中，并且和-1比较，如果不等于-1，再次调回到上述循环。 　　3.8.9 函数谢幕 　　此时，已经运行到函数的最后，然后返回到_init中，然后又运行到_init函数的最后，并返回__libc_csu_init__中。你肯定已经忘了吧！此时仍然在循环处理中呢！但是首先我们完成之前的承诺。 　　3.8.10 承诺过你的使用debugger进入prog2 　　开始吧！需要记住一点的是：GDB总是显示你将要执行的下一行或者下一条指令。 　　运行调试器，打开disassemble-next-line，这样它就会总是显示下一条将要执行的指令的汇编代码，然后我们在_init函数将要调用__do_global_ctors_aux函数的地方设置一个断点。 　　输入r继续运行程序，到达断点处。再输入si单步执行指令，现在我们进入了__do_global_ctors_aux函数内部。后面你会看到若干次我并没输入任何指令，但是GDB却继续执行，这是因为我只是按了回车而已，GDB默认会重复上条指令。所以，如果我按下回车，GDB将会按照输入si继续执行。 　　好的，现在我们已经执行完程序最开始的部分，接下来将要执行真正的代码了。 　　我想知道加载完指针之后会是什么样，所以输入了p/x $eax，意思是以十六进制的形式打印寄存器%eax的内容。它不等于-1，所以我们假定程序将继续执行循环。现在由于我的最后一条指令是print指令，所以我不能按回车继续执行了，下次我就得输入si了。 　　这部分代码很有意思。我们一步步调用来看看。现在我们已经进入了我们自己写的函数a_constructor。因为GDB是能看到我们的源代码的，所以它在下一行给出了我们源码。又因为我打开了disassemble-next-line，所以它也会给出对应的汇编代码。这个例子中输出了函数最开始的部分，对应了函数的声明，所以我们得到了三行汇编。有意思吧？现在，我输入n命令，这个时候我们写的prinf就会被调用了。第一个n跳过了程序最开始的部分，第二个n执行prinf，第三个n执行了函数的结尾部分。如果你想知道为什么你需要在函数最开始和结束部分做些处理的话，现在，你使用GDB的单步调试应该能知道答案了吧。 　　之前，我们已经把a_constructor字符串的地址作为printf的参数保存到了栈里，因为编译器足够的智能，发现实际上puts函数才是我们想要的，所以它调用了puts函数。 　　因为我们正在运行中来调试程序，所以我们看到了a_constructor打印出了上面的内容。后括号}对应了函数的结尾部分，被显示出来了。提示一下，如果你不清楚leave指令的话，实际上它做了一下操作： 　　继续执行，我们就退出了函数，并返回了调用函数。这里我又不得不输入si了： 　　我比较好奇，并且再次看了一下：这次，我们的函数指针指向了-1，所以，程序退出了循环。 　　注意，我们现在退回到了_init。 　　现在，程序跳转回__libc_csu_init函数，然后我们输入q退出了调试器。以上是我之前说的调试过程。现在我们回到__libc_csu_init__函数，这里还有另外一个循环要处理，我就不再进入循环单步分析了，但是我会概述一下。 　　3.9 回到__libc_csu_init__ 　　我们刚刚经历了冗长的时间来分析一个汇编语言写的循环，这个用汇编写的循环要比上一个更加复杂。所以我留给读者自行分析。这里我贴出对应的C代码： 　　3.10 这是另一个函数的循环调用 　　__init__数组里面是什么呢？你肯定不会想到。你也可以在这个阶段自定义代码。这时刚刚从运行我们自定义的构造函数的_init函数返回，这意味着，在这个数组里面的内容将会在构造函数完成之后运行。你能通过某种方式告诉编译器你想在这个阶段运行某个你自定义的函数。这个函数也会收到和main函数相同的参数。 　　我们并不这么做，因为这和之前的动作基本差不多。现在，我们返回到__lib_csu_init函数中，你还记得会返回到哪里吗？ 　　3.11 程序将返回__libc_start_main__ 　　它调用了我们的main函数，然后把main函数的返回值传递给exit()函数。 　　exit()函数运行了更多的循环 　　exit()函数按照注册顺序依次运行了在at_exit()中注册的函数。然后会运行另外一个循环，这次的循环是在__fini_数组中定义的。在运行完这些函数之后，就会调用析构函数。如下所示： 　　四、这个程序，把上面所有的过程联系了起来 　　编译并运行这个函数（这里我将其命名为hooks.c），输出如下： 　　五、结尾 　　现在我们再来回顾一下整个过程，这次你就不会对它感到陌生了吧。