C程序运行的背后(1)

一个成功的男人背后,至少有一个伟大的女人;一个不成功的男人,至少有一双手。

而一个C程序,无论成功不成功,它的背后一定有一个操作系统,一个shell,一套工具链。

世界本就不公平。隐藏在显而易见的事实背后的,你若能看透,便可以站在对自己公平的那一端。

1、进程地址空间

一个进程一旦建立,就会自认为占有4G内存(X86_32),这个内存被称作虚拟内存,也就是进程的地址空间。在Linux下,进程地址空间的布局大致如下图所示,其中的用户空间大致由这些部分组成:

  1. 代码段
  2. 初始化数据段
  3. 未初始化数据段

这些段,反映到ELF格式的目标文件(object file)中,就又可能由许多不同的节(section)组成。节这个东西更加细致复杂,暂且不表。

 

代码段

保存的是可执行指令,通常是只读的,防止指令被程序自身修改。但程序是无法防止被人为修改,否则哪来那么多的修改器。Vim就可以直接编辑二进制文件,指令的机器码任意修改。

存储实例:

       push  %ebp

       movl  %esp, %ebp

 

初始化数据段

保存的是已初始化了的全局变量和静态变量,它可以进一步划分为只读区域和可读写区域。

存储实例:

       Char *string = “hello world”(全局)

           “hello world”在只读区域,指针string在可读写区域

       而Char string[] = “hello world”(全局)

          就只存储string在读写区域中。因为string已被分配存储空间。

       Static int class = 6 (全局/局部)

          全局的容易理解。局部静态变量的意义,在于函数调用完后,其占用的存储单元也不被释放。如此便不可以存放到栈中,而又已被初始化,那么存放到这个段自然是合理的。

 

未初始化数据段

通常称为bss段,名字来自于“block started by symbol”—由符号开始的块。存放于此段的变量,在程序执行之前就被初始化为0或Null指针。

注意,未赋值的指针会被初始化为空指针!如果程序中定义的指针没有初始化,而后面又引用它指向的内存区域,那么在Linux下会引发“段错误”。

 

这就是个狗皮膏药,用处大,却难搞。函数调用时,对栈的操作基本上由编译器完成。函数一旦被调用,就会生成一个栈帧(stack frame),栈帧的范围由两个 “栈指针”寄存器%ebp、%esp限定。

存储实例:

  Caller的返回地址;

  Caller的寄存器信息,如%ebp,%eax;

  Callee自身的局部变量

 

用户手动分配内存的区域,malloc和free,谁用谁知道。另外,共享库和动态加载的模块,也存放于堆中。

 

那么问题来了,实际编译好的目标文件是否真的是这样的呢?

以一个非常简单的C程序—memlayout.c—作为例程:

int main()  {

    return 0;

}

 用GCC分别编译生成memlayout.o和memlayout文件,并查看它们的内存布局:

[root@localhost ~]# size memlayout.o
   text       data        bss        dec        hex    filename
     66          0          0         66         42    memlayout.o
[root@localhost ~]# size memlayout
   text       data        bss        dec        hex    filename
   1055        272          4       1331        533    memlayout

这个程序没有定义任何的变量,由memlayout.o可以看出,data、bss为0是符合预期的。

段依然还是那些段,可最终的可执行文件如何却把它们都搞大了?

我并没有调用exit,为何程序自动流产?

男人的直觉也很准的,特别是程序出轨的时候。凭男人的直觉,我想,一定是编译器(实质是链接器)在某个地方插了一脚。

这也是一个细琐的问题,先做简要说明,容以后再表。

 

2、程序的生命周期

编译好的C程序是躺在磁盘里的,这时只能叫文件。加载到内存并撒腿狂奔的时候,才叫进程。老师们也告诉过我们,一个运行的“hello world”也是一个进程。所以一定要先有一个进程环境,程序才有狂奔的空间。我的家里没有草原,所以董小姐没有理我。

一个C程序的前世今生大概是这样的:

  • Shell首先创建一个子进程,设置好进程环境;
  • 子进程调用execve而陷入内核;
  • 内核调用加载器程序,加载器清理子进程环境后,再加载可执行文件到子进程环境中;
  • 加载器跳转到该程序的入口点(entry point),开始执行C启动代码;
  • 调用main函数,执行真正的C程序;
  • 调用_exit,把控制交还给内核。

也就是说,在写好的main函数之前,编译器添加了一段C启动代码,是C程序执行之前的准备工作;在main函数之后,编译器至少添加(调用)了_exit()来保证进程的正确终止。这也是为什么,中间目标文件和最终可执行文件size相差悬殊,用户空间的程序总会终结的原因。

posted @ 2014-12-29 22:17  陈小硕  阅读(4430)  评论(15编辑  收藏  举报