【面经笔记】函数调用过程

叙述函数调用的过程

http://blog.csdn.net/wangyezi19930928/article/details/16921927

当发生函数调用的时候:

1、调用者函数把被调函数所需要的参数按照与被调函数的形参顺序相反的顺序压入栈中,即:从右向左依次把被调函数所需要的参数压入栈;

2、调用者函数使用call指令调用被调函数,并把call指令的下一条指令的地址当成返回地址压入栈中(这个压栈操作隐含在call指令中);

3、在被调函数中,被调函数会先保存调用者函数的栈底地址(push ebp),然后更新调用者函数的栈顶地址,即:当前被调函数的栈底地址(mov ebp,esp);

4、在被调函数中,从ebp的位置处开始存放被调函数中的局部变量和临时变量,并且这些变量的地址按照定义时的顺序依次减小,即:这些变量的地址是按照栈的延伸方向排列的,先定义的变量先入栈,后定义的变量后入栈;

所以,发生函数调用时,入栈的顺序为:

• 参数N
• …..
• 参数1
• 函数返回地址
• 上一层调用函数的EBP/BP
• 局部变量1
• ….
• 局部变量N

---

esp：堆栈指针寄存器，指向当前栈帧顶部
ebp：基址指针寄存器，指向当前栈帧底部
eax：累加寄存器，常用于函数返回值
ip： 指令地址寄存器，指向下一条指令的地址
ir ：指令寄存器：临时放置从内存里面取得的程序指令

EBP 基址指针，是保存调用者函数的地址，总是指向函数栈栈底，ESP被调函数的指针，总是指向函数栈栈顶。
首 先,将调用者函数的EBP入栈(pushebp),然后将调用者函数的栈顶指针ESP赋值给被调函数的EBP(作为被调函数的栈底,movebp,esp),此时,EBP寄存器处于一个非常重要的位置,该寄存器中存放着一个地址(原EBP入栈后的栈顶),以该地址为基准,向上(栈底方向)能获取返回地址、参数值,向下(栈顶方向)能获取函数的局部变量值,而该地址处又存放着上一层函数调用时的EBP值;

---

函数调用时，执行call指令：将返回地址入栈，并跳转到被调用的地址
函数返回时，先执行leave指令：恢复ebp寄存器，弹出栈中保存的ebp。再执行ret指令：弹出返回地址，跳转到返回地址。

---

_stdcall, _cdecl，_fastcall区别

http://www.jb51.net/article/44652.htm

• _stdcall（StandardCall）是C++的标准调用方式，参数采用从右到左的压栈方式，被调函数自身在返回前清空堆栈，WIN32 Api都采用_stdcall调用方式。

• _cdecl（C Declaration的缩写）是C的缺省调用方式，参数采用从右到左的压栈方式，传送参数的内存栈由调用者维护。

• thiscall 仅仅应用于C++成员函数。this指针存放于CX寄存器，参数从右到左压。thiscall不是关键词，因此不能被程序员指定。参数个数不定的，由调用者清理堆栈，否则由函数自己清理堆栈。

• _fastcall调用较快，它通过CPU内部寄存器传递参数。

WINDOWS的函数调用时需要用到栈（STACK，一种先入后出的存储结构）。当函数调用完成后，栈需要清除，这里就是问题的关键，如何清除？？

如果我们的函数使用了__cdecl，那么栈的清除工作是由调用者。这样带来了一个棘手的问题，不同的编译器产生栈的方式不尽相同，那么调用者能否正常的完成清除工作呢？答案是不能。如果使用__stdcall，上面的问题就解决了，函数自己解决清除工作。所以，在跨平台的调用中，我们都使用__stdcall（虽然有时是以WINAPI的样子出现）。

那么为什么还需要_cdecl呢？当我们遇到这样的函数如fprintf()它的参数是可变的，不定长的，被调用者事先无法知道参数的长度，事后的清除工作也无法正常的进行，因此，这种情况我们只能使用_cdecl。