In the previous blog's Browse call stack (a), I showed how to observe the invocation stack's information in WinDbg: The return address of the function, the parameter, and the return value. This information is stored in a fixed place according to certain rules. This rule is the calling convention (calling convention).
The calling convention is not a fresh concept in the computer world, and has been given a lot of relevant literature to give a detailed introduction. A more comprehensive introduction can be found on Wikipedia's related pages. However, if you, like me, feel that this concept is a highly mystical winter in the first contact with the calling convention, please follow me in this blog to see his origins, his scope and his purpose.
Why do I need to call a convention?
Before we introduce the definition of the calling convention, let's take a look at why we need a winter winter, called the calling convention. If you understand the assembly language (if you don't understand, it will be a little hard to see this paragraph, but I try to interpret the relevant knowledge of the Assembly as clearly as possible), then recall how we made a function call.
Assembly language provides a command, call PTR, its function is to cs:ip (instruction segment: instruction pointer, determines the next execution of the instructions of the address) pressure stack, and modify the CPU instruction pointer, make a jump. At the end of the function, we use another instruction, RET, whose function is to remove the return address from the stack and jump to that instruction.
Assembly language Here only provides the command to jump, as a function of another important part of the parameter transfer, the way is very flexible, you can pass the register value, you can call the stack pass value, you can pass a specific memory value (similar to global variables). This information is then read from the register, stack, or memory in the called function. Imagine if the invoked function was written by one programmer, and the caller was another programmer, then there was a convention between the two to pass the argument.
The emergence of high-level languages hides the problem. When writing a generic C + + program, we usually do not have to worry about the underlying implementation of the parameter pass, but that doesn't mean that the problem does not recur-we just push the responsibility to the compiler. The compiler, as a computer program, always works in accordance with certain rules, each of which corresponds to a calling convention.
Over time, the calling conventions of those classical rules have become a familiar winter and winter:
A familiar calling convention
Before introducing these invocation specifications, I want to explain that the calling specification that follows is on the 32-bit x86 processor Windows platform. The reason for limiting the scope to 32-bit processors is that the 16-bit processor has exited the CPU history stage, and 64 microprocessors have only one calling specification, whether IA64 or AMD64--only 32-bit processors present hundreds of famous, hundred-Star scenes. Yes, of course you do. The calling specification is a concept bound to the processor architecture because it involves too many processor architecture details such as registers. The focus is on Windows because my current job involves only this platform.
The source of the following table is from the old New thing and Zhang Yi's csdn column, and made appropriate changes.
First, all the calling specifications follow the rules: The return value is stored in Edx:eax, Edi,esi, and EBP,EBX is reserved memory. (That is, functions can use any of these registers without fear of destroying the caller's register state)
calling convention Name |
Cleanup stack |
Parameter pressing stack order |
Note |
Cdecl |
Caller (Caller) |
From right to left |
Variable parameters (such as printf) are allowed because the caller cleans the stack |
StdCall |
Callee (callee) |
From right to left |
Typically used in Windows APIs and COM, as well. NET and native code calls, the default calling convention. Incidentally, the WINAPI macros used by the API calling convention in Windows are __stdcall on the PC and wince on the __cdecl. |
ThisCall (Microsoft) |
Callee (callee) |
From right to left |
Basically equivalent stdcall, except this pointer is passed with ECX |
Fastcall (Microsoft) |
Callee (callee) |
From right to left |
Similar to stdcall, but chooses two parameters that can be placed first in the register from left to right, in ECX and edx |