C语言内存模型 (C memory layout)

 一. 内存模型                                                                        　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

1. .text

    代码区(code section)。由编译器链接器生成的可执行指令，程序执行时由加载器（loader）从可执行文件拷贝到内存中。为了安全考虑，防止别的区域更改代码区数据（即可执行指令），代码区具有只读属性。另一个方面，代码区通常具有可共享性（sharable），即在内存中只有一份代码区，如编译器，假如同时有多个编译任务在执行，这些编译任务会共享编译器的代码区，但同时各个编译任务又有自己独立的区域。

2. .rodata

    只读数据区(read-only section)。包含：只读全局变量，只读字符串变量，只读静态（static）变量。程序执行时由加载器（loader）从可执行文件拷贝到内存中。

3. .data

    可写数据区(RW section)。包括：可写全局变量，可写静态(static)变量。程序执行时由加载器（loader）从可执行文件拷贝到内存中。

4. . bss

    未初始化数据区(un-initialized section)。包括：未初始化或初始化为零的全局变量，未初始化或初始化为零的静态（static）变量。为了减小可执行文件的大小，在可执行文件中bss区只是一个占位符。在程序执行时，加载器（loader）根据bss区的大小，在内存中开辟相应空间，同时将这些内存空间全部初始化为零。

    .text, .rodata, .data, .bss四个区域，统称为编译时内存(compiler-time memory)，顾名思义，这些区域的大小在编译时就可以决定。

5. heap

    堆区。对于C语言而言，heap指程序运行时(run-time)由malloc, calloc, realloc等函数分配的内存。

6. stack

    栈区。每一次函数调用，都会发生一次压栈操作，被压栈数据称为一个栈帧(stack frame)，有多少次函数调用（包括main()函数），栈区就有多少个栈帧。相应的，每一次函数调用返回，都会相应的发生一次出栈操作，栈帧就会减少一个。

    函数调用时，根据压栈的顺序，依次需要压栈的数据包括：调用函数(caller funtion)的上下文环境（context environment），如寄存器；函数返回地址；被调用函数(called funtion)的参数列表；被调用函数的非静态(static)局部变量。

    当栈区溢出(stack overflow/underflow)时，栈区数据被污染，程序执行错误，甚至“跑飞"(函数返回地址被修改)。

7. 示例代码

                1
                /*
                 empty-main.c 
                */
                2 #include <stdio.h>
34int main(void)
5{
6return0;
7 }

             1
            /*
             hello-mac.c 
            */
             2
             3 #include <stdio.h>
 4 #include <stdlib.h>
 5 6int g_init_2[2] = {1, 2};            /* .data */ 7constint gc_int_3[3] = {1, 2, 3};   /* .rodata */ 8int g_initWithZero_4[4] = {0};       /* .bss */ 9int g_unInit_5[5];                   /* .bss */1011externint mac(int a, int b, int c);
1213int main(void)
14{
15staticint s_init_6[6] = {1, 2, 3, 4, 5, 6};            /* .data */16staticconstint sc_int_7[7] = {1, 2, 3, 4, 5 ,6, 7};   /* .rodata */17staticint s_initWithZero_8[8] = {0};                   /* .bss */18staticint s_unInit_9[9];                               /* .bss */1920int mac_out;                            /* stack */21int *heap_10 = (int*)malloc(10 * sizeof(int)); /* heap */2223     mac_out = mac(1, 2, 3);
24     printf("mac=%d\n", mac_out);    /* .rodata string */2526    free(heap_10);
27return0;
28 }

            1
            /*
             mac.c 
            */
            2
            3 #include <stdio.h>
45int mac(int a, int b, int c)
6{
7return a + b * c;??
8 }

二. 如何获得compiler-time memory consumption：.text, .rodata, .data, .bss　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

首先，必须说明的是，下面提到的三种方法，题主也有很多没有弄明白的地方，尤其是对于对齐的考虑。不过使用objdump -x的方法，可以很清楚的验证，上面示例代码中对变量属于哪个区的描述都是正确的。

1. 借助size/objdump等工具

    首先，我们使用gcc在Linux平台编译链接上面的hello-mac.c和mac.c两个源文件：

$ gcc -o hello-mac hello-mac.c mac.c
$ gcc -o empty-main empty-main.c

然后我们可以使用size或者objdump工具来比较两个可执行文件的区别。

    我们尝试用size命令看看：

$ size hello-mac empty-main
   text    data     bss     dec     hex filename
   15406161842340924 hello-mac
   111555281675     68b empty-main

其中text表示只读区（.text和.rodata），data为.data初始化的全局变量或静态变量，bss表示未初始化全局变量或静态变量。dec为前三者的和，hex为dec列的16进制表示。

    这里之所以使用empty-main，是为了剔除掉glibc等系统占用的内存。

    比较两个可行文件的data区，我们发现hello-mac多出64 byte， 而实际上我们的代码中一共有.data：4 * (2（g_init_2）+ 6(s_init_6)) =  32 byte, why??? ==> align？？？

    再比较bss区，hello-mac多出172 byte，而实际上我们的代码中一共有.bss： 4*（4 + 5 + 8 + 9）= 104 bytes, why???

    我们尝试用objdump -x命令：

$ objdump -x hello-mac
$ objdump -x empty-main

在输出中，我们能查看到更加详细的信息，比size的信息要多得多。包括我们前面定义的全局变量和静态变量分别属于.rodata, .data和.bss，均有清晰的交待。

    比较两个输出文件的.data，我们发现hello-mac多出了0x28=40byte，与size命令给出的64byte不符，与实际32 byte并不相符。why？？？

    比较bss区，hello-mac多出0xb0=176byte，与size命令给出的172byte不符，与实际算出的104byte也不相符。why???

    比较rodata区，hello-mac多出72byte，与实际算出的40byte不符，why？？

2. 借助于链接器选项，生成map文件

 对于GCC，添加-Xlinker -Map=<filename>到链接器选项即可；对于ARMCC，添加-L--map -L--list=<filename>到链接器选项即可；对于MSVS，按照Linker->debugging->Generate Map Files -> Yes修改就可以得到可执行文件的map问价。我们再分析map文件就可以了。下面用gcc做实验。

$ gcc -c hello-mac.c -o hello-mac.o
$ gcc -c mac.c -o mac.o
$ gcc -o hello-mac -Xlinker -Map=hello-mac.map hello-mac.o mac.o

    通过查看map文件我们能清晰的看出来哪个源文件(在map中为上面生成的.o目标文件)包含哪些函数，变量，各自占了.text, .rodata, .data, .bss多少空间。这个方法对于全局变量，函数代码区大小都能查到，但是，静态变量并没有被查到。

 三. 如何获得run-time memory consumption: heap, stack     　　                 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

    在上面的内存模型中，我们会发现heap和stack是向着相反的方向增长，那么，如果两者相遇重叠了会发生什么？要么发生heap的数据被stack覆盖，或者相反。

    在调试程序时，常常会遇到“Segment Fault”, “Stackoverflow", "Heap crash”, 最常见的原因就是在于此。那么

I.  是否能在程序运行时获取程序当前的stack, heap大小，以及stack, heap的总容量呢？

II. 有时一个平台上出现SegFault，但是在另一个平台就没有了，如数组越界访问，为什么？

    这部分还不知道有什么工具能看。TBD

四. 参考                                                                                          　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　

http://blog.sina.com.cn/s/blog_af9acfc60101bbcy.html

http://blog.csdn.net/gl23838/article/details/7924254

http://www.geeksforgeeks.org/memory-layout-of-c-program/

原文：http://www.cnblogs.com/xjsxjtu/p/3795105.html