FROM: http://kelvinh.github.io/blog/2013/08/05/windows-x64-calling-conventions/
Windows平台X64函数调用约定与汇编代码分析
起因
整件事源自于公司的一个公共模块，有很多项目都依赖于这个公共模块，我们项目是其中之一。假定依赖的函数原型为：
int add(int a, int b, int c, int d, int e)
某一天，这个公共模块将 add 函数增加了一个参数，即原型变成了下面这样：
int add(int a, int b, int c, int d, int e, int f)
但是公共模块的负责人没有通知我们，所以我们并不知道这个变化。
如果是常规调用，即直接用 add(...) 来调用的话，在公共模块增加参数后，那么编译就会提示出错的。但是我们是采用的动态调用，如下：
typedefint (*FunctionPtr)(inta, intb, intc, intd, inte); HMODULEh = ::LoadLibraryEx(L"CommonModule.dll", ...); FunctionPtrpf = reinterpret_cast<FunctionPtr>(::GetProcAddress(h, "add")); intret = pf(1, 2, 3, 4, 5); //...
因此，对这种调用方式来说，在编译阶段，调用者是无法知晓 CommonModule.dll 的改动的。
可是，按照常规讲，虽然编译阶段没有出错，那么在运行的时候，总会发生异常，例如crash之类的啊。可奇怪的就在这一点，运行时也一切正常，QA测试也没发现什么bug，于是项目就正常release了。
但在release之后，另一个使用这个公共模块的项目出了问题，具体什么问题我不太清楚，后来检查了之后才发现是公共模块的接口有变化。于是，我们项目的老大们对这个公共模块的人大发牢骚：改接口也不通知，现在产品都release了，如果因为这个原因而大面积出问题，你怎么跟客户解释！！
可是，我们QA测试的时候不是一点问题都没有么，到底是怎么回事呢？
分析
于是，我写了如下的一个例子，来分析一番：
#include<iostream>intadd(inta, intb, intc, intd, inte) {return a + b + c + d + e; } intmain() {intr = add(1, 2, 3, 4, 5);std::cin.get(); }
上面例子中 main() 函数调用 std::cin.get() 是为了让程序阻塞在那里，方便我们能够来得及在程序退出之前将WinDbg给Attach到进程上去。下面的就是在WinDbg里面看到的 main() 函数和 add() 函数的汇编代码（能看到如下代码的前提是，在Visual Studio编译之前，把相关的优化选项以及安全检查选项给关掉，不然Visual Studio会插入一些安全检查的代码，同时会直接把 add() 函数给优化掉）（忘了说明，编译采用的是VS2012）：
0:000> uf Project1!main
Project1!main [d:\codelabs\functest\c++\project1\source.cpp @ 7]:
7 00000001`3ff21730 4883ec48 sub rsp,48h
8 00000001`3ff21734 c744242005000000 mov dword ptr [rsp+20h],5
8 00000001`3ff2173c 41b904000000 mov r9d,4
8 00000001`3ff21742 41b803000000 mov r8d,3
8 00000001`3ff21748 ba02000000 mov edx,2
8 00000001`3ff2174d b901000000 mov ecx,1
8 00000001`3ff21752 e8a9ffffff call Project1!add (00000001`3ff21700)
8 00000001`3ff21757 89442430 mov dword ptr [rsp+30h],eax
9 00000001`3ff2175b 488b0dee180000 mov rcx,qword ptr [Project1!_imp_?cinstd (00000001`3ff23050)]
9 00000001`3ff21762 ff15f8180000 call qword ptr [Project1!_imp_?get?$basic_istreamDU?$char_traitsDstdstdQEAAHXZ (00000001`3ff23060)]
10 00000001`3ff21768 33c0 xor eax,eax
10 00000001`3ff2176a 4883c448 add rsp,48h
10 00000001`3ff2176e c3 ret
0:000> uf Project1!add
Project1!add [d:\codelabs\functest\c++\project1\source.cpp @ 3]:
3 00000001`3ff21700 44894c2420 mov dword ptr [rsp+20h],r9d
3 00000001`3ff21705 4489442418 mov dword ptr [rsp+18h],r8d
3 00000001`3ff2170a 89542410 mov dword ptr [rsp+10h],edx
3 00000001`3ff2170e 894c2408 mov dword ptr [rsp+8],ecx
4 00000001`3ff21712 8b442410 mov eax,dword ptr [rsp+10h]
4 00000001`3ff21716 8b4c2408 mov ecx,dword ptr [rsp+8]
4 00000001`3ff2171a 03c8 add ecx,eax
4 00000001`3ff2171c 8bc1 mov eax,ecx
4 00000001`3ff2171e 03442418 add eax,dword ptr [rsp+18h]
4 00000001`3ff21722 03442420 add eax,dword ptr [rsp+20h]
4 00000001`3ff21726 03442428 add eax,dword ptr [rsp+28h]
5 00000001`3ff2172a c3 ret
如果对于x64的CPU结构不太熟悉的话，上面的汇编着实不太好理解，下面给出一张x64结构的CPU寄存器构造图1：
从图上可以看到，X64架构相对于X32架构的主要变化，是将原来所有的寄存器都扩大了一倍，例如EAX现在扩充成RAX，同时，又新增加了从R8到R15这8个64位的寄位器。
知道了寄存器的结构，还是不足以理解上面的汇编函数调用，此外，还需要知道Intel X64汇编函数调用的一些约定2：
RCX, RDX, R8, R9 are used for integer and pointer arguments in that order left to right.
XMM0, 1, 2, and 3 are used for floating point arguments.
Additional arguments are pushed on the stack left to right.
Parameters less than 64 bits long are not zero extended; the high bits contain garbage.
It is the caller's responsibility to allocate 32 bytes of "shadow space" (for storing RCX, RDX, R8, and R9 if needed) before calling the function.
It is the caller's responsibility to clean the stack after the call.
Integer return values (similar to x86) are returned in RAX if 64 bits or less.
Floating point return values are returned in XMM0.
Larger return values (structs) have space allocated on the stack by the caller, and RCX then contains a pointer to the return space when the callee is called. Register usage for integer parameters is then pushed one to the right. RAX returns this address to the caller.
The stack is 16-byte aligned. The "call" instruction pushes an 8-byte return value, so the all non-leaf functions must adjust the stack by a value of the form 16n+8 when allocating stack space.
Registers RAX, RCX, RDX, R8, R9, R10, and R11 are considered volatile and must be considered destroyed on function calls.
RBX, RBP, RDI, RSI, R12, R14, R14, and R15 must be saved in any function using them.
Note there is no calling convention for the floating point (and thus MMX) registers.
Further details (varargs, exception handling, stack unwinding) are at Microsoft's site.
上面这段话里面有几个关键点：1. 一个函数在调用时，前四个参数是从左至右依次存放于RCX、RDX、R8、R9寄存器里面；2. 剩下的参数从左至右顺序入栈；3. 调用者负责在栈上分配32字节的“shadow space”，用于存放那四个存放调用参数的寄存器的值（亦即前四个调用参数）；4. 调用者负责清理栈；5. 被调用函数若是整数返回，则返回值会被存放于RAX；6. 栈是16字节对齐的，“call”指令会入栈一个8字节的返回值（注：即函数调用前原来的RIP指令寄存器的值），这样一来，栈就对不齐了，所以，所有非叶子结点调用的函数，都必须调整栈分配方式为16n+8，来使栈对齐。
这样一来，上面的汇编代码就好懂了：
主调函数（main）将栈指针RSP下移0x48，即分配栈空间；
将最后一个调用参数5入栈，存放于[RSP + 0x20]处，这样一来，栈上面空出的 0x48 - 0x20 = 0x28 = 40 = 32 + 8 的空间就用于存放本地变量，其中8字节应该是用来对齐栈的；
将前四个参数分别放入约定中的那四个寄存器；
调用
add函数（在这个指令中，栈指针RSP又下移了8个字节，这8个字节用来存放RIP指针的值）；进入
add函数，把在四个寄存器中的参数又放回栈上（栈上的用于存放这四个寄存器空间就是“shadow space”，如果需要，由被调用者负责将这四个寄存器的值放回栈3），然后执行加操作，最后的结果存放于RAX中；返回
main函数后，取出RAX的值，再放回本地变量的栈空间中；...
上面的指令对栈操作比较多，我画了一个调用栈的分配情况图（用Window Paint画的，花的时间不比写这篇博客的时间短，中间还画错了一次。。 =_=#!）：
另外，再附上一张MSDN上画的栈分配的示例图4（和上面我画的差不多，只不过我画的是针对于具体的例子）：
结论
按照分析中所指出的，在X64平台的函数调用中，函数前四个参数之外的参数会被入栈，如上面的栈分配图所示，实际上在主调函数中，分配的栈参数空间上面还有本地变量空间，所以，如果偶然多了一个参数的话，其实没有关系，不会导致crash，只不过这个参数的值会是无效的。既然参数值无效，程序运行应该会出bug才对，后来问了这个公共模块的负责人，才知道这个新加的参数没有使用。。擦，没有使用，你乱改接口，新加参数干嘛。。
附：X86的几种调用约定
| Name | Arguments | Stack unwinding |
|---|---|---|
| Win32 (stdcall) | push stack, right to left | callee |
| Native C++ (thiscall) | push stack, right to left, "this" pointer in ECX | callee |
| COM (stdcall for C++) | push stack, right to left, then "this" | callee |
| fastcall | arg1 in ECX, arg2 in EDX, remaining pushed to stack, right to left | callee |
| cdecl | push stack, right to left | caller |
看完X86这些乱七八糟的调用约定，再回头看看X64，只有一种，太幸福了。。
另外要补充的一点是，在一般情况下，X64平台的RBP栈基指针被废弃掉，只作为普通寄存器来用，所有的栈操作都通过RSP指针来完成，这必然会要求RSP的值在一个函数中不能改动，所以，像 push 和 pop 这类会改变RSP值的指令是不能随便使用的。
参考文档
http://software.intel.com/sites/default/files/m/d/4/1/d/8/Introduction_to_x64_Assembly.pdf
http://blogs.msdn.com/b/oldnewthing/archive/2004/01/14/58579.aspx
http://msdn.microsoft.com/en-us/library/zthk2dkh.aspx
http://msdn.microsoft.com/en-us/library/ew5tede7.aspx
公司内部一个介绍Windows X64 Debug的PPT，这个就不放出来了 :-D
Footnotes:
这张图来自Intel的X64汇编介绍文档：http://software.intel.com/sites/default/files/m/d/4/1/d/8/Introduction_to_x64_Assembly.pdf
同1，这段约定也来自上面的文档
这句说明（The callee has the responsibility of dumping the register parameters into their shadow space if needed.）来自MSDN：http://msdn.microsoft.com/en-us/library/zthk2dkh.aspx
来源：http://msdn.microsoft.com/en-us/library/ew5tede7.aspx