【编程语言】进程中栈空间的参数返回值以及局部变量的分布

      在进程中对于局部变量是怎么分配的，以及函数是怎么调用的其实也就是讲解栈区的具体使用过程。（ 下面代码图摘要于网络）

      首先，我们要知道，栈中存放的是一个个被调函数所对应的堆栈帧，当函数fun1被调用，则fun1的堆栈帧入栈，fun1返回时，fun1的堆栈帧出栈。什么是堆栈帧呢，堆栈帧其实就是保存被调函数返回时下一条执行指令的指针、主调函数的堆栈帧的指针、主调函数传递给被调函数的实参(如果有的话)、被调函数的局部变量等信息的一个结构。

堆栈帧结构如图所示:

        首先，我们要说明的是如何区分每个堆栈帧，或者说，如何知道我现在在使用哪个堆栈帧。和栈密切相关的有2个寄存器，一个是ebp,一个是esp,前者可以叫作栈基址指针，后者可以叫栈顶指针。对于一个堆栈帧来说，ebp也叫堆栈帧指针,它永远指向这个堆栈帧的某个固定位置(见上图)，所以可以根据ebp来表示一个堆栈帧，可以通过对ebp的偏移加减，来在堆栈帧中来来回回的访问。esp则是随着push和pop而不断移动。因此根据esp来对堆栈帧进行操作。
再来讲一下上图，一个堆栈帧的最顶部，是实参，然后是return address,这个值是由主调函数中的call命令在call调用时自动压入的，不需要我们关心，previous frame pointer,就是主调函数的堆栈帧指针，也就是主调函数的ebp值。ebp偏移为正的都是被调函数的局部变量。

 

1. int function(int a, int b, int c)  

2. {  

3.     char buffer[14];  

4.     int     sum;  

5.     sum = a + b + c;  

6.     return sum;  

7. }  

8.    

9. void main()  

10. {  

11.     int     i;  

12.     i = function(1,2,3);  

13. }  

 

其中函数function的堆栈帧

 

注释:

           1.function中,buffer是14个字节，sum是4个字节，照例应该是申请18个字节，但是第11行，程序申请了20个字节。这是时间效率和空间效率之间的一种折衷，因为Intel i386是32位的处理器，其每次内存访问都必须是4字节对齐的，而高30位地址相同的4个字节就构成了一个机器字。因此，如果为了填补 buffer[14]留下的两个字节而将sum分配在两个不同的机器字中，那么每次访问sum就需要两次内存操作，这显然是无法接受的。这些都是跟编译器相关的优化技术。

           2.我们再来看一下在函数function中是如何将a、b、c的和赋给sum的。前面已经提过，在函数中访问实参和局部变量时都是以堆栈帧指针为基址，再加上一个偏移，而Intel i386体系结构下的堆栈帧指针就是ebp，为了清楚起见，我们在图7中标出了堆栈帧中所有成分相对于堆栈帧指针ebp的偏移。这下图6中12至16的计算就一目了然了，8(�p)、12(�p)、16(�p)和-20(�p)分别是实参a、b、c和局部变量sum的地址，几个简单的 add指令和mov指令执行后sum中便是a、b、c三者之和了。另外，在gcc编译生成的汇编程序中函数的返回结果是通过eax传递的，因此在图6中第 17行将sum的值拷贝到eax中。

           3.我们再来看一下函数function执行完之后与其对应的堆栈帧是如何弹出堆栈的。图6中第21行的leave指令将堆栈帧指针 ebp拷贝到esp中，于是在堆栈帧中为局部变量buffer[14]和sum分配的空间就被释放了；除此之外，leave指令还有一个功能，就是从堆栈中弹出一个机器字并将其存放到ebp中，这样ebp就被恢复为main函数的堆栈帧指针了。第22行的ret指令再次从堆栈中弹出一个机器字并将其存放到指令指针eip中，这样控制就返回到了第36行main函数中的addl指令处。addl指令将栈顶指针esp加上12，于是当初调用函数 function之前压入堆栈的三个实参所占用的堆栈空间也被释放掉了。至此，函数function的堆栈帧就被完全销毁了。前面刚刚提到过，在gcc编译生成的汇编程序中通过eax传递函数的返回结果，因此图6中第38行将函数function的返回结果保存在了main函数的局部变量i中.

 

//

进程的内存使用情况比较复杂，这是因为：

         · 进程申请的内存不一定真正会被用到

        · 真正用到的内存也不一定是只有该进程自己在用 (比如动态共享库)

 

Effective VM    :     52120 KB
Mapped          :    352 KB
Effective mapped:     76.6 KB
Sole use        :     72 KB

Per file memory use
ld-2.3.4.so                   : VM   94208 B, M   90112 B, S    8192 B
prog                          : VM    8192 B, M    8192 B, S    8192 B
libc-2.3.4.so                 : VM    1180 KB, M 221184 B, S   16384 B

可以看出，虽然虚拟地址空间是52396KB，实际映射(a.k.a. 分配)的空间是352KB，这和ps给出的结果一致。再看"Effective Mapped"这个值，仅为76.6 KB。这个值的计算方法是：

有效的实际使用内存 = 该进程独占的内存 + 共享的内存A /共享A的进程数目 + 共享的内存B /共享B的进程数目 + ...

虽然并不十分准确，但"Effective Mapped"已经足以说明进程所占用内存的实际大小了。