程序员的自我修养

过度优化的问题自然很多，这里不再描述。只说解决方法：

可以使用volatile关键字来试图阻止过度优化，volatile基本可以做到两件事情： 1、阻止编译器为了提高速度将一个变量缓存到寄存器内而不写回。 2、阻止编译器调整操作volatile变量的指令顺序。

但即使这样，还是有问题。 因为即使volatile能够阻止编译器调整指令顺序，也无法阻止CPU动态调度换序。下面举例说明：Singleton模式

volatile T* pInst = 0;
T *GetInstance()
{
        if (pInst == NULL) {
                lock();
                if (pInst == NULL)
                        pInst = new T;
                unlock();
        }
        return pInst;
}

这段代码的问题是CPU的乱序执行。因为C++里的new操作包含了两个步骤：1、分配内存。2、调用构造函数。所以，pInst = new T包含了三个步骤： (1) 分配内存。 (2) 在内存的位置上调用构造函数。 (3) 将内存的地址赋值给pInst。在这三步中，(2)和(3)的顺序是可以颠倒的。也就是说，完全有可能出现这样的情况：pInst的值已经不是NULL，但对象仍然没有构造完毕。这时候如果出现另外一个对GetInstance的并发调用，此时第一个if内的表达式pInst == NULL 为false，所以这个调用会直接返回尚未构造完全的对象的地址(pInst)以提供给用户使用。那么程序这个时候会不会崩溃就取决于这个类的设计如何了。 解决这一问题，即多线程环境中，CPU的换序问题，可以通过barrier指令来完成。

#define barrier() __asm__ volatile("lwsync")
volatile T* pInst = 0;
T *GetInstance()
{
        if (pInst == NULL) {
                lock();
                if (pInst == NULL) { // 通过临时对象指针和屏障指令，就保证了上面(2)(3)的顺序执行
                        T *temp = new T;
                        barrier();
                        pInst = temp; 
                }
                unlock();
        }
        return pInst;
}

OK，完美解决～～

本篇笔记全文摘自后面参考文献列出的地址，不过原文中有一些错别字，我这里把错别字改了改，然后也是按照自己机器上代码的结果来进行演示。再结合本书前面第6章“6.5 Linux内核装载ELF过程简介”来进行说明。1、开始 The question is simple: how does linux execute my main()? Through this document, I'll use the following simple C program to illustrate how it works. It's called "execute_main.c"

int main()
{
   return 0;
}

2、编译 gcc -o execute_main execute_main.c3、What's in the executable?

i4@i4:~/文档/tempfile$ objdump -f execute_main

execute_main:     file format elf32-i386
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x08048300

4、What's at address "0x08048300", that is, starting address?

i4@i4:~/文档/tempfile$ objdump -d execute_main

The output is a little bit long so I'll not paste all the output from objdump. Our intention is see what's at address 0x08048300. Here is the output.

Disassembly of section .text:

08048300 <_start>:
 8048300:	31 ed                	xor    %ebp,%ebp
 8048302:	5e                   	pop    %esi
 8048303:	89 e1                	mov    %esp,%ecx
 8048305:	83 e4 f0             	and    $0xfffffff0,%esp
 8048308:	50                   	push   %eax
 8048309:	54                   	push   %esp
 804830a:	52                   	push   %edx
 804830b:	68 30 84 04 08       	push   $0x8048430
 8048310:	68 c0 83 04 08       	push   $0x80483c0
 8048315:	51                   	push   %ecx
 8048316:	56                   	push   %esi
 8048317:	68 b4 83 04 08       	push   $0x80483b4
 804831c:	e8 cf ff ff ff       	call   80482f0 <__libc_start_main@plt>
 8048321:	f4                   	hlt    

Looks like some kind of starting routine called "_start" is at the starting address. What it does is clear a register, push some values into stack and call a function. According to this instruction, the stack frame should look like this. ---------------- %eax ---------------- %esp ---------------- %edx ---------------- 0x8048430 ---------------- 0x80483c0 ---------------- %ecx ---------------- %esi ----------------Stack Top 0x80483b4 ---------------- Now, as you already wonder,we've got a few questions regarding this stack frame. Q1: What are those hex values about? Q2: What's at address 80482f0, which is called by _start? (PS: 即上面反汇编代码中804831c: e8 cf ff ff ff call 80482f0 <__libc_start_main@plt>) Q3: Looks like the assembly instructions doesn't initialize any register with possibly meaningful values. Then who initializes the registers? (PS: 个人认为这个很重要，后面有较多篇幅来描述) A1: The hexa values. If you look at disassembled output from objdump carefully, you can answer this question easily.再把反汇编代码摘出来，然后给出答案：

08048430 <__libc_csu_fini>: ......
080483c0 <__libc_csu_init>: ......
080483b4 <main>: ......

Right now, let's not care about these stuffs. And basically, all those hexa values are function pointers. A2: What's at address 80482f0?

080482f0 <__libc_start_main@plt>:
 80482f0:	ff 25 04 a0 04 08    	jmp    *0x804a004
......

Here *0x804a004 is a pointer operation. It just jumps to an address stored at address 0x804a004.那么这里地址0x804a004处是什么呢？我们看下面代码(PS: 原文这里又说了说关于动态链接的内容，这些内容在书第7章已经讲了，我这里不再陈述。大家跟着看下代码就明白了。)

i4@i4:~/文档/tempfile$ objdump -R execute_main

execute_main:     file format elf32-i386

DYNAMIC RELOCATION RECORDS
OFFSET   TYPE              VALUE 
08049ff0 R_386_GLOB_DAT    __gmon_start__
0804a000 R_386_JUMP_SLOT   __gmon_start__
0804a004 R_386_JUMP_SLOT   __libc_start_main

看到没，上面0x804a004其实是__libc_start_main函数的地址，是动态链接里面动态重定位里的一种类型。即，其实我们是想调用__libc_start_main函数。5、What's __libc_start_main? Now the ball is on libc's hand. __libc_start_main is a function in libc.so.6. If you look for __libc_start_main in glibc source code, the prototype looks like this.

int __libc_start_main(
                  int (*main) (int, char * *, char * *), 
                  int argc, 
                  char * * ubp_av, 
                  void (*init) (void), 
                  void (*fini) (void), 
                  void (*rtld_fini) (void), 
                  void (* stack_end)
);

总结： 到此我们知道： all the assembly instructions do is set up argument stack and call _libc_start_main. What this function does is setup/initialize some data structures/environments and call our main(). Let's look at the stack frame with this function prototype. ---------------- %eax this is 0 ---------------- %esp stack_end ---------------- %edx _rtlf_fini ---------------- 0x8048430 _libc_csu_fini ---------------- 0x80483c0 _libc_csu_init ---------------- %ecx argv ---------------- %esi argc ----------------Stack Top 0x80483b4 main ---------------- According to this stack frame, esi, ecx, edx, esp, eax registers should be filled with appropriate values before __libc_start_main() is executed. And clearly this registers are not set by the startup assembly instructions shown before. Then, who sets these registers? Now I guess the only thing left. The kernel. Now let's go back to our third question. A3: What does the kernel do? When we execute a program by entering a name on shell, this is what happens on Linux.(PS: 下面的描述太长，其实描述的也就是书里第6章“6.5 Linux内核装载ELF过程简介”的内容。我在这段英文后面给出大概的执行流程) 1: The shell calls the kernel system call "execve" with argc/argv. The kernel system call handler gets control and start handling the system call. In kernel code, the handler is "sys_execve". On x86, the user-mode application passes all required parameters to kernel with the following registers. %ebx : pointer to program name string %ecx : argv array pointer %edx : environment variable array pointer. 2: The generic execve kernel system call handler, which is do_execve, is called. What it does is set up a data structure and copy some data from user space to kernel space and finally calls search_binary_handler(). Linux can support more than one executable file format such as a.out and ELF at the same time. For this functionality, there is a data structure "struct linux_binfmt", which has a function pointer for each binary format loader. And search_binary_handler() just looks up an appropriate handler and calls it. In our case, load_elf_binary() is the handler. To explain each detail of the function would be lengthy/boring work. So I'll not do that. If you are interested in it, read a book about it. As a picture tells a thousand words, a thousand lines of source code tells ten thousand words (sometimes). Here is the bottom line of the function. It first sets up kernel data structures for file operation to read the ELF executable image in. Then it sets up a kernel data structure: code size, data segment start, stack segment start, etc. And it allocates user mode pages for this process and copies the argv and environment variables to those allocated page addresses. Finally, argc, the argv pointer, and the envrioronment variable array pointer are pushed to user mode stack by create_elf_tables(), and start_thread() starts the process execution rolling. 这两段描述的大概流程是：shell ---> execve (同时传递argc, argv) ---> sys_execve (用户模式下的一些内容传递给内核模式里的一些寄存器，即%ebx, %ecx, %edx。这三个的具体内容上面1:里有) ---> search_binary_handler() ---> load_elf_binary()。最后这个load_elf_binary()设置了不少内容，设置完之后就是返回到用户模式下运行e_entry的入口函数。 在入口函数_start()执行之前，栈的内容如下： ---------------- env pointer ---------------- argv pointer ----------------Stack Top argc ---------------- And the assembly instructions gets all information from stack by

pop %esi 		<--- get argc
mov %esp, %ecx		<--- get argv (actually the argv address is the same as the current stack pointer.)

And now we are all set to start executing.6、What about the other registers? For %esp, this is used for stack end in application program. After popping all necessary information, the _start rountine simply adjusts the stack pointer (%esp) by turning off lower 4 bits from esp register. This perfectly makes sense since actually, to our main program, that is the end of stack. For edx, which is used for rtld_fini, a kind of application destructor, the kernel just sets it to 0 with the following macro.#define ELF_PLAT_INIT(_r) do { \ _r->ebx = 0; _r->ecx = 0; _r->edx = 0; \ _r->esi = 0; _r->edi = 0; _r->ebp = 0; \ _r->eax = 0; \} while (0) The 0 means we don't use that functionality on x86 linux.7、Summing up Here is what happens. 1: GCC build your program with crtbegin.o/crtend.o/gcrt1.o And the other default libraries are dynamically linked by default. Starting address of the executable is set to that of _start. 2: Kernel loads the executable and setup text/data/bss/stack, especially, kernel allocate page(s) for arguments and environment variables and pushes all necessary information on stack. 3: Control is pased to _start. _start gets all information from stack setup by kernel, sets up argument stack for __libc_start_main, and calls it. 4: __libc_start_main initializes necessary stuffs, especially C library(such as malloc) and thread environment and calls our main. 5: our main is called with main(argv, argv) Actually, here one interesting point is the signature of main. __libc_start_main thinks main's signature as main(int, char **, char **) If you are curious, try the following prgram.

main(int argc, char** argv, char** env)
{
    int i = 0;
    while(env[i] != 0)
    {
       printf("%s\n", env[i++]);
    }
    return(0);
}

8、Conclusion On Linux, our C main() function is executed by the cooperative work of GCC, libc and Linux's binary loader.9、Reference [1] http://linuxgazette.net/issue84/hawk.html [2] http://www.fsl.cs.sunysb.edu/~siddhi/ELF.pdf

cat /proc/pid/maps

例如：

i4@i4:~/文档/proger$ ./p162.elf &
[1] 6178
i4@i4:~/文档/proger$ cat /proc/6178/maps
08048000-080ee000 r-xp 00000000 08:07 7875904    /home/i4/文档/proger/p162.elf
080ee000-080f0000 rw-p 000a5000 08:07 7875904    /home/i4/文档/proger/p162.elf
080f0000-080f2000 rw-p 00000000 00:00 0 
093ba000-093dc000 rw-p 00000000 00:00 0          [heap]
b7764000-b7765000 r-xp 00000000 00:00 0          [vdso]
bfde5000-bfe06000 rw-p 00000000 00:00 0          [stack]

其中： 第一列是VMA的地址范围 第二列是VMA的权限，r代表可读，w代表可写，x代表可执行，p代表私有，s代表共享 第三列是偏移，表示VMA对应的Segment在映像文件中的偏移 第四列是映像文件所在设备的主设备号和次设备号 第五列是映像文件的节点号 最后一列是映像文件的路径

一、程序的编译过程，目标文件里究竟是什么从源程序到目标文件的生成过程最简单的编译命令是gcc helloworld.c，它包含了以下几个步骤：预处理、编译、汇编、链接，下面分别简介。预处理：处理#define宏定义、#if #ifdef等条件编译指令、#include预编译指令，删除注释，添加行号和文件名标识，保留所有的#pargma编译器指令，经过预编译后的文件为.i文件。预编译命令为：gcc -E hello.c -o hello.i或者cpp hello.c > hello.i编译：把预处理完得文件进行一系列的词法分析、语法分析、语意分析及优化后产生的汇编代码文件。编译命令为gcc -S hello.i -o hello.s。现在版本的gcc把预编译和编译两个步骤合并成一个步骤，使用ccl程序来完成，命令为ccl hello.c。也可以使用gcc -S hello.c -o hello.s直接从.c文件生成.s汇编文件。汇编：将汇编代码转变成机器可以执行的指令，每一条汇编语句几乎都对应一条机器指令。命令为：as hello.s -o hello.o或者gcc -c hello.s -o hello.o或者我们最熟悉的gcc -c hello.c -o hello.o链接：当我们的程序模块调用a另一个模块中b的函数（foo()）或变量时，在编译的阶段编译器并不知道函数foo的地址，所以暂时把调用foo的指令的目标地址搁置，等待最后链接的时候由连接器去将这些指令的目标地址修正。把目标文件和库一起链接成可执行文件。最常见的库时运行时库。目标文件中的格式目标文件就是源代码编译后但未进行链接的那些中间文件，它和可执行文件的内容和结构其实很相似，所以一般和可执行文件采用同一种格式存储，那就是ELF格式。与ELF格式相对应的是Windows平台下的PE格式，它们都是COFF格式的变种。不光是可执行文件和目标文件按照ELF格式存储，动态链接库（.so）和静态链接库（.a）都按照ELF格式存储。ELF格式的文件可分为以下4类：1 可重定位文件（Relocatable File）：这类文件包含了代码和数据，可以被用来链接成可执行文件或共享目标文件，静态链接库也可以归为这一类，代表是Linux的.o文件2 可执行文件（Executable File）：这类文件包含了可以直接执行的程序，它的代表就是ELF可执行文件，它们一般都没有扩展名，如/bin/bash文件3 共享目标文件（Shared Object File）：这种文件包含了代码和数据，可以在以下两种情况下使用。一种是链接器可以使用这种文件跟其他的可重定位文件和共享目标文件链接，产生新的目标文件。第二种是动态链接器可以将这几个共享目标文件与可执行文件结合，作为进程影响的一部分来运行。4 核心转储文件（Core Dump File）：当进程意外终止时，系统可以将该进程的地址空间的内容以终止时的一些其他信息转储带核心转储文件。上面几种文件在file命令下会显示出相应的类型。目标文件里有什么：ELF文件最重要的结构是ELF文件头（ELF Header）：ELF文件头里定义了ELF魔数、文件机器字节长度、数据存储方式、版本、运行平台、ABI版本、ELF重定位类型、硬件平台、硬件平台版本、入口地址、程序头入口和长度、段表的位置和长度及段得数量等。三个最重要的段：代码段(.text)、数据段(.data)和只读数据段(.rodata)、BSS段(.bss)可以用objdump -s -x -d hello.o来分析各个段得内容，-d表示反汇编，-s表示把各段内容用16进制打印，-x表示详细数据。 顾名思义，.text段主要存放可执行的代码数据；.data段保存的是已经初始化了的全局变量和静态变量；.rodata段保存只读数据，一般是程序里的只读变量（如const修饰的变量）和字符串常量；bss保存未初始化的全局变量和静态变量。除此之外，还有一些常见的段，如.comment段存放编译器版本信息，比如字符串“GCC:(GNU)4.2.0”.dubug段存放调试信息.dynamic存放动态链接信息.hash段存放符号哈希表.line段存放调试时的行号表.note段存放额外的编译器信息.strtab段存放字符串表，用于存储ELF文件中用到的各种字符串，比如符号的名字.shstrtab段存放段表中用到的字符串，最常见的就是段名.symtab段是符号表，通过符号表就能知道这个符号在哪个段，以及在这个段的具体位置，还有这个符号在字符串表中的位置Section Table(段表)也是其中一个段，它保存了各个段的信息，如段名、段的长度、在文件中的偏移、读写权限及段的其他属性.rel.text段是一个重定位表，正如前面所说的，链接器在处理目标文件时，需要对目标文件的某些部位进行重定位，即代码段和数据段中那些对绝对地址的引用的位置，这些重定位的信息都记录在ELF文件的重定位表里通过ELF文件头的信息可以找到段表的位置，从而找到各个段得位置和信息。可以用readelf -S hello.o命令详细查看ELF文件中各段的信息。二、可执行文件的装载程序执行时所需要的指令和数据必须都在内存中才能正常运行，最简单的办法就是将程序运行时所需要的指令和数据全部都装入内存，这样程序就能顺利执行，这就是最简单的静态装入的方法。但是程序所需要的内存数量可能大于物理内存，静态装入就不太现实。 后来研究发现，程序运行时具有局部性原理，所以我们可以将程序最常用的部分驻留在内存中，而将一些不太常用的数据存放在磁盘上，这就是动态装载的原理。 覆盖装入和页映射是两种典型的动态装入方法。覆盖装入就是如果两个模块不会同时运行，则可以使这两个模块共用一块内存，需要哪个模块的时候就装入。现在基本已经淘汰了。 页映射是虚拟存储机制的一部分，它随着虚拟存储的发明而诞生。在页映射机制中，程序装载和操作的单位都是页。最常见的Inter IA32处理器一般都使用4KB大小的页。 假设程序所有的指令和数据总和为32kB,那么程序总共分为8页，将其编号为P0-O7，并假设物理内存只有16kB，编号为F0-F3。如果程序刚开始执行时的入口地址为P0，这时装载管理器发现程序的P0不在内存中，于是将F0分配给P0，并将P0的内容装入F0；运行一段时间后，程序需要用到P5，于是装载管理器将P5装入F1，就这样，当程序用到P3和P6时，它们分别装入到了F2和F3。 很明显，如果这时程序只需要P0，P3，P5和P6这4个页，那么程序就能一直运行下去。但是如果这时候需要访问P4，那么装载管理器需要最初选择，它必须放弃目前正在使用的4个物理内存页中的一个来装载P4。至于选择哪个页，可以有多种算法选择，比如FIFO先入先出算法，LRU最近最少使用算法等。 其实，上面所说的装载管理器就是操作系统的存储管理器。从操作系统的角度看可执行文件的装载 从操作系统的角度看，一个进程最关键的特征就是它拥有独立的虚拟地址空间，这使得它有别于其他进程。这在http://blog.csdn.net/vividonly/archive/2011/05/04/6393516.aspx一文中有详细解释。要使一个可执行程序得以执行，首先必须创建一个进程，然后装载相应的可执行文件并且执行。在有虚拟存储的情况下，上述过程最开始只要做三件事： 1 创建一个独立的虚拟地址空间。这时候并不设置虚拟地址页和物理地址页的映射关系，这些映射关系等到后面程序发生页错误的时候再进行设置。当发生页错误时，操作系统将从物理内存中分配一个物理页，然后将该“缺页”从磁盘中读取到内存中再设置缺页的虚拟页与物理页的映射关系。这都是通过CPU的MMU来实现的。 2 读取可执行文件头，并且建立虚拟空间与可执行文件的映射关系。这个映射关系在进程中叫做VMA（虚拟内存区域）。比如对于.text段，在创建进程后，会在进程相应的数据结构中设置一个.text段的VMA，记录了它在虚拟空间的地址以及它在ELF文件中的偏移。当程序执行发生页错误，通过查找VMA结构来定位错误页在可执行文件的位置，把可执行文件的那部分内容装入刚分配的物理内存中，进程从刚才页错误的位置重新开始执行。 3 将CPU的指令寄存器设置为可执行文件的入口地址，启动运行。操作系统通过设置CPU的指令寄存器将控制权转交给进程。这里的入口地址就是ELF文件头中的入口地址。