calling convention and name decoration in DLLs (i)The calling convention (calling convention) refers to a protocol that is established in a programming language in order to implement a function call. This protocol specifies the way in which parameters are transferred in the function of the language, whether the parameters are mutable, and by whom the stack is handled. Different languages define different calling conventions. In C + +, in order to allow operator overloading and function overloading, the C + + compiler tends to rewrite the symbolic name of each entry point in accordance with a rule to allow multiple usages of the same name (with different parameter types or different scopes) without breaking the existing C-based linker. This technique is often referred to as name mangling or name decoration (named decoration). Many C + + compiler vendors have chosen their own name-decorating scheme. therefore, in order for modules written in other languages (such as Visual Basic applications, Pascal or FORTRAN applications, and so on) to be able to invoke functions of DLLs written in C + +, the function must be exported using the correct calling convention. And do not let the compiler make any name decorations on the functions to be exported.
1. calling convention (calling convention) The calling convention handles issues such as determining the order in which the function parameters are passed in and out of the stack (by the caller or callee), and the name-decoration conventions used by the compiler to identify the function names. The following calling conventions are defined in Microsoft VC + + 6.0, and we will analyze them in conjunction with assembly language:
1
, __cdecl__CDECL is a calling convention that is used by default for C/s + + and MFC programs, or it can be specified manually by adding the __CDECL keyword to the function declaration. With the __CDECL convention, the function arguments are stacked in the right-to-left order, and the arguments are popped by the calling function to clean up the stack. Therefore, a function that implements a mutable parameter can only use that calling convention. Because each function that uses the __CDECL convention contains the code to clean up the stack, the resulting executable file size is larger. __cdecl can be written as _cdecl. below will be a concrete example to analyze the __CDECL convention: in VC + + to create a new WIN32 console project, named Cdecl. The code is as follows: int __cdecl Add (int a, int b); //function declaration void Main () { Add (; ) //Function call} int __cdecl Add (int a, int b) //Function Implementation { return (A + b);} The disassembly code at the function call is as follows: ; ADD (ush );p 2         &NBsp; parameters from right to left into the stack, first pressed into the 2push 1 Press-in 1call @ILT +0 (ADD) ( 00401005) call function implementation add esp,8 called by the function to clear the stack
2
, __stdcallThe __stdcall calling convention is used to invoke the Win32 API function. When the __stdcal convention is used, the function parameters are stacked in the right-to-left order, and the called function cleans up the stack of the transfer parameters before returning, and the number of function parameters is fixed. Since the function body knows the number of arguments passed in, the called function can clean up the stack of passed arguments directly with a ret n instruction before returning. __stdcall can be written as _stdcall. or that example, replace the __CDECL convention with __stdcall: int __stdcall ADD (int a, int b) {return (A + b);} function call at the disassembly code: ; ADD (ush );p 2 parameters from right to left into the stack, first pressed into the 2push 1 Press-in 1call @ILT +10 (ADD) (0040100f) Call function implementation function implementation part of the disassembly code: ;int __stdcall Add (int a, int b) push ebpmov ebp,espsub esp,40hpush ebxpush esipush edilea edi,[ebp-40h]mov ecx,10hmov eax,0cccccccchrep stos dword ptr [Edi];return (a + b); mov & nbsp; eax,dword ptr [ebp+8]add Eax,dword ptr [ebp+0ch]pop edipop esipop ebxmov esp,ebppop ebpret 8 , Qing-Stack
3
, __fastcallThe __fastcall convention is used in situations where performance requirements are high. The __fastcall convention places two parameters of the function that are not larger than 4 bytes (DWORD) from the left side in the ECX and edx registers, and the remaining parameters are still transferred from right to left, and the called function cleans up the stack of the routing parameters before returning. __fastcall can be written as _fastcall. is still a similar example, when the function calling convention is __fastcall, the number of function arguments is increased by 2: int __fastcall Add (int A, double b, int c, int d) {return (A + B + C +) d);} Assembly code for the function call Section: ; ADD (1, 2, 3, 4);p ush 4 the latter two parameters from right to left into the stack, first pressed into the 4mov edx,3 put 3 of type int into edxpush 40000000h ; Press into a 2push of type double  0MOV   &Nbsp; ecx,1 put 1 of type int into ecxcall @ Ilt+0 (ADD) (00401005) call function implementation The disassembly code of the function implementation Section: ; int __fastcall Add (int A, double b, int c, int d) push ebpmov EBP, espsub esp,48hpush ebxpush esipush edipush ecxlea edi,[ebp-48h]mov ecx,12hmov eax,0cccccccchrep stos dword ptr [edi]pop ecxmov DWORD ptr [ebp-8],edxmov DWORD ptr [Ebp-4],ecx;return (A + B + C + D); fild & nbsp; dword ptr [ebp-4]fadd qword ptr [ebp+8]fiadd dword ptr [ebp-8]fiadd dword PTR [ebp+10h]call __ftol (004011b8) pop edipop  ESIPOP &Nbsp; ebxmov esp,ebppop ebpret 0ch keywords __cdecl, __stdcall and __ Fastcall can be added directly before the function to be exported, or it can be selected in the Setting...->c/c++->code generation of the compilation environment. Their corresponding command-line arguments are/gd,/gz, and/gr, respectively. The default state is/GD, which is __cdecl. When the keyword before the output function is different from the selection in the compilation environment, the keyword directly before the output function is valid. from: http://blog.csdn.net/thimin/article/details/1529386
Calling convention and name decoration in DLLs (i)
