青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

posts - 15, comments - 9, trackbacks - 0, articles - 0

詳解函數調用約定

Posted on 2009-05-15 17:30 沙漠里的海豚 閱讀(798) 評論(1)  編輯 收藏 引用 所屬分類: c/c++標準

在編寫windows程序時,我們經常發現一些函數的前面帶有WINAPI等的關鍵字(不知道這樣描述是否準確,請明白的讀者聯系本人更正),如windows的消息響應函數定義如下:

1 LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM) ;

這里的LRESULT在windows中被定義為long型,而CALLBACK則被定義成了__stacall,仔細看了一下,在WINDEF.H中還包含如下定義:
1#define CALLBACK    __stdcall
2#define WINAPI      __stdcall
3#define WINAPIV     __cdecl
4#define APIENTRY    WINAPI
5#define APIPRIVATE  __stdcall
6#define PASCAL      __stdcall

那么,這里的__stacall、__cdecl到底是什么意思呢,又有什么作用呢?我經過查找相關資料對其有了些許淺顯的了解,這里與大家一起分享。

我們知道,在C語言中假設我們有這樣一個函數定義:
int function_add(int a, int b);
那么只要用
1int x = 3, y = 5;
2int result = function_add(x, y);
這樣的方式就可以對函數進行調用了。但是,在計算機中,當高級語言程序被編譯成計算機可以識別的機器碼時,有一個問題就凸現出來:在CPU中,計算機沒有辦法知道一個函數調用需要多少個參數、這些參數是什么樣的,也沒有硬件可以保存這些參數。也就是說,計算機并不知道應該怎么給這個函數傳遞參數,傳遞參數的工作必須由函數調用者和函數本身來協調。為此,計算機提供了一種被稱為棧的數據結構來支持函數的參數傳遞。

棧是一種先進后出的數據結構,棧有一個存儲區、一個棧頂指針。棧頂指針指向堆棧中第一個可用的數據項(被稱為棧頂)。用戶可以在棧頂的上方向堆棧中加入數據,這個操作被稱為壓棧(Push),壓棧以后,棧頂自動變成新加入數據項的位置,棧頂指針也隨之修改。用戶也可以從堆棧中取出棧頂元素,這個操作被稱為彈出棧(pop),彈出棧以后,棧頂的下一個元素變成棧頂,棧頂指針隨之修改。

函數調用時,調用者依次把參數壓棧,然后調用函數,函數被調用以后,在堆棧中取出數據,并進行計算。函數計算結束以后,或者調用者、或者函數本身修改堆棧,使堆棧恢復原狀。問題的關鍵就在這里,到底應該如何清除棧呢?

函數調用需要進行參數傳遞,在參數傳遞過程中有兩個很重要的問題必須得到明確說明:
    1. 當參數個數多于一個時,按照什么樣的順序把參數壓入棧中
    2. 函數調用后,由誰來負責把堆棧恢復原狀

在高級語言中,函數調用約定就是用來說明這兩個問題的。常見的函數調用約定有:
        stdcall
        cdecl
        fastcall
        thiscall
        naked call

下面一一進行介紹。

一、stdcall調用約定

stdcall,也可寫作__stdcall,很多時候被稱為pascal調用約定,因為pascal是早期很常見的一種教學用計算機程序設計語言,其語法嚴謹,使用的函數調用約定就是stdcall。幾乎我們寫的每一個WINDOWS API函數都是__stdcall類型的。在Microsoft C++系列的C/C++編譯器中,常常用PASCAL宏來聲明這個調用約定,類似的宏還有WINAPI和CALLBACK(如文章開頭引用的在WINDEF.H頭文件中的定義)。

stdcall調用約定聲明的語法為(以前面的function_add函數為例):
int __stdcall function_add(int a,int b);

stdcall調用約定意味著:
(1) 參數從右向左壓入堆棧
(2) 函數自身修改堆棧
(3) 函數名自動加前導的下劃線,后面緊跟一個@符號,其后緊跟著參數的大小

以上述這個函數為例,參數b首先被壓棧,然后是參數a,函數調用function_add(1, 2)調用處翻譯成匯編語言將變成:

      push       2                      // 第二個參數入棧
      push       1                      // 第一個參數入棧
      call         function_add    // 調用參數,注意此時自動把cs:eip入棧

而對于函數自身,則可翻譯為:
      push       ebp         // 保存ebp寄存器,該寄存器將用來保存堆棧的棧頂指針,可以在函數退出時恢復
      mov    ebp, esp        // 保存堆棧指針
      mov    eax,[ebp + 8H]      // 堆棧中ebp指向位置之前依次保存有ebp, cs:eip, a, b, ebp +8指向a
      add     eax,[ebp + 0CH]      // 堆棧中ebp + 12處保存了b
      mov    esp, ebp       //  恢復esp
      pop     ebp
      ret       8

而在編譯時,這個函數的名字被翻譯成_function@8

  注意不同編譯器會插入自己的匯編代碼以提供編譯的通用性,但是大體代碼如此。其中在函數開始處保留esp到ebp中,在函數結束恢復是編譯器常用的方法。

  從函數調用看,2和1依次被push進堆棧,而在函數中又通過相對于ebp(即剛進函數時的堆棧指針)的偏移量存取參數。函數結束后,ret 8表示清理8個字節的堆棧,函數自己恢復了堆棧。

由于不同的編譯器產生棧的方式不盡相同,調用者就不一定能夠正常的完成堆棧的清除工作,但函數本身自己可以解決清除工作,所以,在跨平臺的程序開發中的函數調用,我們通常都使用__stdcall約定,windows下的絕大多數函數也都是stdcall調用。既然如此,為什么還需要__cdecl呢?別著急,接著往下看。

二、cdecl調用約定

cdecl,也可寫作__cdecl,又稱為C調用約定,是C/C++語言和MFC程序默認缺省的調用約定,它的定義語法是:

    int function (int a ,int b)         //不加修飾就是C調用約定
     int __cdecl function(int a,int b)  //明確指出C調用約定


采用__cdecl約定時,函數參數按照從右到左的順序入棧,并且由調用函數者把參數彈出棧以清理堆棧。因此,實現可變參數的函數只能使用該調用約定。由于這種變化,C調用約定允許函數的參數的個數是不固定的,這也是C語言的一大特色。同時,由于每一個使用__cdecl約定的函數都要包含清理堆棧的代碼,所以產生的可執行文件大小會比較大。__cdecl可以寫成_cdecl。

對于前面的function函數,使用cdecl后的匯編碼變成:

調用處
  push   1
  push   2
  call     function
  add esp, 8      // 注意:這里調用者在恢復堆棧

  被調用函數_function處
  push    ebp      // 保存ebp寄存器,該寄存器將用來保存堆棧的棧頂指針,可以在函數退出時恢復
  mov    ebp,esp     // 保存堆棧指針
  mov eax,[ebp + 8H]  // 堆棧中ebp指向位置之前依次保存有ebp,cs:eip,a,b,ebp +8指向a
  add eax,[ebp + 0CH]    // 堆棧中ebp + 12處保存了b
  mov esp,ebp     // 恢復esp
  pop ebp
  ret         //  注意,這里沒有修改堆棧


不寫了,累得慌,呵呵 轉載兩篇文章吧

__stdcall,__cdecl,_cdecl,_stdcall,。__fastcall,_fastcall 區別簡介 

1.

今天寫線程函數時,發現msdn中對ThreadProc的定義有要求:DWORD WINAPI ThreadProc(LPVOID lpParameter);

不解為什么要用WINAPI宏定義,查了后發現下面的定義。于是乎需要區別__stdcall和__cdecl兩者的區別; #define CALLBACK __stdcall
#define WINAPI __stdcall
#define WINAPIV __cdecl
#define APIENTRY WINAPI
#define APIPRIVATE __stdcall
#define PASCAL __stdcall
#define cdecl _cdecl
#ifndef CDECL
#define CDECL _cdecl
#endif

幾乎我們寫的每一個WINDOWS API函數都是__stdcall類型的,首先,需要了解兩者之間的區別: WINDOWS的函數調用時需要用到棧(STACK,一種先入后出的存儲結構)。當函數調用完成后,棧需要清楚,這里就是問題的關鍵,如何清除?? 如果我們的函數使用了_cdecl,那么棧的清除工作是由調用者,用COM的術語來講就是客戶來完成的。這樣帶來了一個棘手的問題,不同的編譯器產生棧的方式不盡相同,那么調用者能否正常的完成清除工作呢?答案是不能。 如果使用__stdcall,上面的問題就解決了,函數自己解決清除工作。所以,在跨(開發)平臺的調用中,我們都使用__stdcall(雖然有時是以WINAPI的樣子出現)。那么為什么還需要_cdecl呢?當我們遇到這樣的函數如fprintf()它的參數是可變的,不定長的,被調用者事先無法知道參數的長度,事后的清除工作也無法正常的進行,因此,這種情況我們只能使用_cdecl。到這里我們有一個結論,如果你的程序中沒有涉及可變參數,最好使用__stdcall關鍵字。

2.

__cdecl,__stdcall是聲明的函數調用協議.主要是傳參和彈棧方面的不同.一般c++用的是__cdecl,windows里大都用的是__stdcall(API)

__cdecl是C/C++和MFC程序默認使用的調用約定,也可以在函數聲明時加上__cdecl關鍵字來手工指定。采用__cdecl約定時,函數參數按照從右到左的順序入棧,并且由調用函數者把參數彈出棧以清理堆棧。因此,實現可變參數的函數只能使用該調用約定。由于每一個使用__cdecl約定的函數都要包含清理堆棧的代碼,所以產生的可執行文件大小會比較大。__cdecl可以寫成_cdecl。
__stdcall調用約定用于調用Win32 API函數。采用__stdcall約定時,函數參數按照從右到左的順序入棧,被調用的函數在返回前清理傳送參數的棧,函數參數個數固定。由于函數體本身知道傳進來的參數個數,因此被調用的函數可以在返回前用一條ret n指令直接清理傳遞參數的堆棧。__stdcall可以寫成_stdcall。
__fastcall約定用于對性能要求非常高的場合。__fastcall約定將函數的從左邊開始的兩個大小不大于4個字節(DWORD)的參數分別放在ECX和EDX寄存器,其余的參數仍舊自右向左壓棧傳送,被調用的函數在返回前清理傳送參數的堆棧。__fastcall可以寫成_fastcall

3.

__stdcall:

_stdcall 調用約定相當于16位動態庫中經常使用的PASCAL調用約定。

 
在32位的VC++5.0中PASCAL調用約定不再被支持(實際上它已被定義為__stdcall。除了__pascal外,__fortran和__syscall也不被支持),取而代之的是__stdcall調用約定。兩者實質上是一致的,即函數的參數自右向左通過棧傳遞,被調用的函數在返回前清理傳送參數的內存棧,但不同的是函數名的修飾部分(關于函數名的修飾部分在后面將詳細說明)。

_stdcall是Pascal程序的缺省調用方式,通常用于Win32 Api中,函數采用從右到左的壓棧方式,自己在退出時清空堆棧。VC將函數編譯后會在函數名前面加上下劃線前綴,在函數名后加上"@"和參數的字節數。

_cdecl:

_cdecl c調用約定, 按從右至左的順序壓參數入棧,由調用者把參數彈出棧。對于傳送參數的內存棧是由調用者來維護的(正因為如此,實現可變參數的函數只能使用該調用約定)。另外,在函數名修飾約定方面也有所不同。

_cdecl是C和C++程序的缺省調用方式。每一個調用它的函數都包含清空堆棧的代碼,所以產生的可執行文件大小會比調用_stdcall函數的大。函數采用從右到左的壓棧方式。VC將函數編譯后會在函數名前面加上下劃線前綴。是MFC缺省調用約定。

__fastcall:

__fastcall調用約定是"人"如其名,它的主要特點就是快,因為它是通過寄存器來傳送參數的(實際上,它用ECX和EDX傳送前兩個雙字(DWORD)或更小的參數,剩下的參數仍舊自右向左壓棧傳送,被調用的函數在返回前清理傳送參數的內存棧),在函數名修飾約定方面,它和前兩者均不同。

_fastcall方式的函數采用寄存器傳遞參數,VC將函數編譯后會在函數名前面加上"@"前綴,在函數名后加上"@"和參數的字節數。

thiscall:

thiscall僅僅應用于"C++"成員函數。this指針存放于CX寄存器,參數從右到左壓。thiscall不是關鍵詞,因此不能被程序員指定。

naked call:

采用1-4的調用約定時,如果必要的話,進入函數時編譯器會產生代碼來保存ESI,EDI,EBX,EBP寄存器,退出函數時則產生代碼恢復這些寄存器的內容。

naked call不產生這樣的代碼。naked call不是類型修飾符,故必須和_declspec共同使用。

另附:

關鍵字 __stdcall、__cdecl和__fastcall可以直接加在要輸出的函數前,也可以在編譯環境的Setting...\C/C++ \Code Generation項選擇。當加在輸出函數前的關鍵字與編譯環境中的選擇不同時,直接加在輸出函數前的關鍵字有效。它們對應的命令行參數分別為/Gz、/Gd和/Gr。缺省狀態為/Gd,即__cdecl。

要完全模仿PASCAL調用約定首先必須使用__stdcall調用約定,至于函數名修飾約定,可以通過其它方法模仿。還有一個值得一提的是WINAPI宏,Windows.h支持該宏,它可以將出函數翻譯成適當的調用約定,在WIN32中,它被定義為__stdcall。使用WINAPI宏可以創建自己的APIs。

名字修飾約定

1、修飾名(Decoration name)
“C”或者“C++”函數在內部(編譯和鏈接)通過修飾名識別。修飾名是編譯器在編譯函數定義或者原型時生成的字符串。有些情況下使用函數的修飾名是必要的,如在模塊定義文件里頭指定輸出“C++”重載函數、構造函數、析構函數,又如在匯編代碼里調用“C””或“C++”函數等。

修飾名由函數名、類名、調用約定、返回類型、參數等共同決定。

2、名字修飾約定隨調用約定和編譯種類(C或C++)的不同而變化。函數名修飾約定隨編譯種類和調用約定的不同而不同,下面分別說明。

a、C編譯時函數名修飾約定規則:

__stdcall調用約定在輸出函數名前加上一個下劃線前綴,后面加上一個“@”符號和其參數的字節數,格式為_functionname@number。

__cdecl調用約定僅在輸出函數名前加上一個下劃線前綴,格式為_functionname。

__fastcall調用約定在輸出函數名前加上一個“@”符號,后面也是一個“@”符號和其參數的字節數,格式為@functionname@number。

它們均不改變輸出函數名中的字符大小寫,這和PASCAL調用約定不同,PASCAL約定輸出的函數名無任何修飾且全部大寫。

b、C++編譯時函數名修飾約定規則:

__stdcall調用約定:
1、以“?”標識函數名的開始,后跟函數名;
2、函數名后面以“@@YG”標識參數表的開始,后跟參數表;
3、參數表以代號表示:
X--void ,
D--char,
E--unsigned char,
F--short,
H--int,
I--unsigned int,
J--long,
K--unsigned long,
M--float,
N--double,
_N--bool,
....
PA--表示指針,后面的代號表明指針類型,如果相同類型的指針連續出現,以“0”代替,一個“0”代表一次重復;
4、參數表的第一項為該函數的返回值類型,其后依次為參數的數據類型,指針標識在其所指數據類型前;
5、參數表后以“@Z”標識整個名字的結束,如果該函數無參數,則以“Z”標識結束。

其格式為“?functionname@@YG*****@Z”或“?functionname@@YG*XZ”,例如
int Test1(char *var1,unsigned long)-----“?Test1@@YGHPADK@Z”
void Test2() -----“?Test2@@YGXXZ”

__cdecl調用約定:
規則同上面的_stdcall調用約定,只是參數表的開始標識由上面的“@@YG”變為“@@YA”。

__fastcall調用約定:
規則同上面的_stdcall調用約定,只是參數表的開始標識由上面的“@@YG”變為“@@YI”。
VC++對函數的省缺聲明是“__cedcl“,將只能被C/C++調用.

CB在輸出函數聲明時使用4種修飾符號
//__cdecl
cb的默認值,它會在輸出函數名前加_,并保留此函數名不變,參數按照從右到左的順序依次傳遞給棧,也可以寫成_cdecl和cdecl形式。
//__fastcall
她修飾的函數的參數將盡肯呢感地使用寄存器來處理,其函數名前加@,參數按照從左到右的順序壓棧;
//__pascal
它說明的函數名使用Pascal格式的命名約定。這時函數名全部大寫。參數按照從左到右的順序壓棧;
//__stdcall
使用標準約定的函數名。函數名不會改變。使用__stdcall修飾時。參數按照由右到左的順序壓棧,也可以是_stdcall;

VC++對函數的省缺聲明是"__cedcl",將只能被C/C++調用.

 

 

注意:

1、_beginthread需要__cdecl的線程函數地址,_beginthreadex和CreateThread需要__stdcall的線程函數地址。

2、一般WIN32的函數都是__stdcall。而且在Windef.h中有如下的定義:

 #define CALLBACK __stdcall

 #define WINAPI  __stdcall

3、extern "C" _declspec(dllexport) int __cdecl Add(int a, int b);

   typedef int (__cdecl*FunPointer)(int a, int b);

   修飾符的書寫順序如上。

4、extern "C"的作用:如果Add(int a, int b)是在c語言編譯器編譯,而在c++文件使用,則需要在c++文件中聲明:extern "C" Add(int a, int b),因為c編譯器和c++編譯器對函數名的解釋不一樣(c++編譯器解釋函數名的時候要考慮函數參數,這樣是了方便函數重載,而在c語言中不存在函數重載的問題),使用extern "C",實質就是告訴c++編譯器,該函數是c庫里面的函數。如果不使用extern "C"則會出現鏈接錯誤。

一般象如下使用:

#ifdef _cplusplus

#define EXTERN_C extern "C"

#else

#define EXTERN_C extern

#endif

#ifdef _cplusplus

extern "C"{

#endif

 EXTERN_C int func(int a, int b);

#ifdef _cplusplus

}

#endif

5、MFC提供了一些宏,可以使用AFX_EXT_CLASS來代替__declspec(DLLexport),并修飾類名,從而導出類,AFX_API_EXPORT來修飾函數,AFX_DATA_EXPORT來修飾變量

AFX_CLASS_IMPORT:__declspec(DLLexport)

AFX_API_IMPORT:__declspec(DLLexport)

AFX_DATA_IMPORT:__declspec(DLLexport)

AFX_CLASS_EXPORT:__declspec(DLLexport)

AFX_API_EXPORT:__declspec(DLLexport)

AFX_DATA_EXPORT:__declspec(DLLexport)

AFX_EXT_CLASS:#ifdef _AFXEXT

   AFX_CLASS_EXPORT

        #else

   AFX_CLASS_IMPORT

6、DLLMain負責初始化(Initialization)和結束(Termination)工作,每當一個新的進程或者該進程的新的線程訪問DLL時,或者訪問DLL的每一個進程或者線程不再使用DLL或者結束時,都會調用DLLMain。但是,使用TerminateProcess或TerminateThread結束進程或者線程,不會調用DLLMain。

7、一個DLL在內存中只有一個實例

DLL程序和調用其輸出函數的程序的關系:

1)、DLL與進程、線程之間的關系

DLL模塊被映射到調用它的進程的虛擬地址空間。

DLL使用的內存從調用進程的虛擬地址空間分配,只能被該進程的線程所訪問。

DLL的句柄可以被調用進程使用;調用進程的句柄可以被DLL使用。

DLLDLL可以有自己的數據段,但沒有自己的堆棧,使用調用進程的棧,與調用它的應用程序相同的堆棧模式。

2)、關于共享數據段

DLL定義的全局變量可以被調用進程訪問;DLL可以訪問調用進程的全局數據。使用同一DLL的每一個進程都有自己的DLL全局變量實例。如果多個線程并發訪問同一變量,則需要使用同步機制;對一個DLL的變量,如果希望每個使用DLL的線程都有自己的值,則應該使用線程局部存儲(TLS,Thread Local Strorage)。



論函數調用約定


在C語言中,假設我們有這樣的一個函數:
  
  int function(int a,int b)
  
  調用時只要用result = function(1,2)這樣的方式就可以使用這個函數。但是,當高級語言被編譯成計算機可以識別的機器碼時,有一個問題就凸現出來:在CPU中,計算機沒有辦法知道一個函數調用需要多少個、什么樣的參數,也沒有硬件可以保存這些參數。也就是說,計算機不知道怎么給這個函數傳遞參數,傳遞參數的工作必須由函數調用者和函數本身來協調。為此,計算機提供了一種被稱為棧的數據結構來支持參數傳遞。

  棧是一種先進后出的數據結構,棧有一個存儲區、一個棧頂指針。棧頂指針指向堆棧中第一個可用的數據項(被稱為棧頂)。用戶可以在棧頂上方向棧中加入數據,這個操作被稱為壓棧(Push),壓棧以后,棧頂自動變成新加入數據項的位置,棧頂指針也隨之修改。用戶也可以從堆棧中取走棧頂,稱為彈出棧(pop),彈出棧后,棧頂下的一個元素變成棧頂,棧頂指針隨之修改。

  函數調用時,調用者依次把參數壓棧,然后調用函數,函數被調用以后,在堆棧中取得數據,并進行計算。函數計算結束以后,或者調用者、或者函數本身修改堆棧,使堆棧恢復原裝。

  在參數傳遞中,有兩個很重要的問題必須得到明確說明:
  
  當參數個數多于一個時,按照什么順序把參數壓入堆棧
  函數調用后,由誰來把堆棧恢復原裝
  在高級語言中,通過函數調用約定來說明這兩個問題。常見的調用約定有:

  stdcall
  cdecl
  fastcall
  thiscall
  naked call

 

  stdcall調用約定
  stdcall很多時候被稱為pascal調用約定,因為pascal是早期很常見的一種教學用計算機程序設計語言,其語法嚴謹,使用的函數調用約定就是stdcall。在Microsoft C++系列的C/C++編譯器中,常常用PASCAL宏來聲明這個調用約定,類似的宏還有WINAPI和CALLBACK。

  stdcall調用約定聲明的語法為(以前文的那個函數為例):
  
  int __stdcall function(int a,int b)
  
  stdcall的調用約定意味著:1)參數從右向左壓入堆棧,2)函數自身修改堆棧 3)函數名自動加前導的下劃線,后面緊跟一個@符號,其后緊跟著參數的尺寸

  以上述這個函數為例,參數b首先被壓棧,然后是參數a,函數調用function(1,2)調用處翻譯成匯編語言將變成:

  push 2        第二個參數入棧
  push 1        第一個參數入棧
  call function    調用參數,注意此時自動把cs:eip入棧

  而對于函數自身,則可以翻譯為:
  push ebp       保存ebp寄存器,該寄存器將用來保存堆棧的棧頂指針,可以在函數退出時恢復
  mov ebp, esp    保存堆棧指針
  mov eax,[ebp + 8H] 堆棧中ebp指向位置之前依次保存有ebp, cs:eip, a, b, ebp +8指向a
  add eax,[ebp + 0CH] 堆棧中ebp + 12處保存了b
  mov esp, ebp    恢復esp
  pop ebp
  ret 8

  而在編譯時,這個函數的名字被翻譯成_function@8

  注意不同編譯器會插入自己的匯編代碼以提供編譯的通用性,但是大體代碼如此。其中在函數開始處保留esp到ebp中,在函數結束恢復是編譯器常用的方法。

  從函數調用看,2和1依次被push進堆棧,而在函數中又通過相對于ebp(即剛進函數時的堆棧指針)的偏移量存取參數。函數結束后,ret 8表示清理8個字節的堆棧,函數自己恢復了堆棧。

  
  cdecl調用約定
  cdecl調用約定又稱為C調用約定,是C語言缺省的調用約定,它的定義語法是:

  int function (int a ,int b) //不加修飾就是C調用約定
  int __cdecl function(int a,int b)//明確指出C調用約定

  在寫本文時,出乎我的意料,發現cdecl調用約定的參數壓棧順序是和stdcall是一樣的,參數首先由右向左壓入堆棧。所不同的是,函數本身不清理堆棧,調用者負責清理堆棧。由于這種變化,C調用約定允許函數的參數的個數是不固定的,這也是C語言的一大特色。對于前面的function函數,使用cdecl后的匯編碼變成:

  調用處
  push 1
  push 2
  call function
  add esp, 8     注意:這里調用者在恢復堆棧

  被調用函數_function處
  push ebp       保存ebp寄存器,該寄存器將用來保存堆棧的棧頂指針,可以在函數退出時恢復
  mov ebp,esp     保存堆棧指針
  mov eax,[ebp + 8H] 堆棧中ebp指向位置之前依次保存有ebp,cs:eip,a,b,ebp +8指向a
  add eax,[ebp + 0CH] 堆棧中ebp + 12處保存了b
  mov esp,ebp     恢復esp
  pop ebp
  ret         注意,這里沒有修改堆棧

  MSDN中說,該修飾自動在函數名前加前導的下劃線,因此函數名在符號表中被記錄為_function,但是我在編譯時似乎沒有看到這種變化。

  由于參數按照從右向左順序壓棧,因此最開始的參數在最接近棧頂的位置,因此當采用不定個數參數時,第一個參數在棧中的位置肯定能知道,只要不定的參數個數能夠根據第一個后者后續的明確的參數確定下來,就可以使用不定參數,例如對于CRT中的sprintf函數,定義為:
  int sprintf(char* buffer,const char* format,...)
  由于所有的不定參數都可以通過format確定,因此使用不定個數的參數是沒有問題的。

  fastcall
  fastcall調用約定和stdcall類似,它意味著:
  
  函數的第一個和第二個DWORD參數(或者尺寸更小的)通過ecx和edx傳遞,其他參數通過從右向左的順序壓棧
  被調用函數清理堆棧
  函數名修改規則同stdcall
  其聲明語法為:int fastcall function(int a, int b)

  thiscall
  thiscall是唯一一個不能明確指明的函數修飾,因為thiscall不是關鍵字。它是C++類成員函數缺省的調用約定。由于成員函數調用還有一個this指針,因此必須特殊處理,thiscall意味著:

  參數從右向左入棧
  如果參數個數確定,this指針通過ecx傳遞給被調用者;如果參數個數不確定,this指針在所有參數壓棧后被壓入堆棧。對參數個數不定的,調用者清理堆棧,否則函數自己清理堆棧為了說明這個調用約定,定義如下類和使用代碼:

  class A
  {
  public:
    int function1(int a,int b);
    int function2(int a,...);
  };

  int A::function1 (int a,int b)
  {
    return a+b;
  }

  #include <stdarg.h>
  int A::function2(int a,...)
  {
    va_list ap;
    va_start(ap,a);
    int i;
    int result = 0;
    for(i = 0 ; i < a ; i ++)
    {
     result += va_arg(ap,int);
    }
    return result;
  }

  void callee()
  {
    A a;
    a.function1(1, 2);
    a.function2(3, 1, 2, 3);
  }

callee函數被翻譯成匯編后就變成:
  //函數function1調用
  00401C1D  push    2
  00401C1F  push    1
  00401C21  lea     ecx,[ebp-8]
  00401C24  call    function1     注意,這里this沒有被入棧

  //函數function2調用
  00401C29  push    3
  00401C2B  push    2
  00401C2D  push    1
  00401C2F  push    3
  00401C31  lea     eax, [ebp-8]    這里引入this指針
  00401C34  push    eax
  00401C35  call    function2
  00401C3A  add     esp, 14h
  
  可見,對于參數個數固定情況下,它類似于stdcall,不定時則類似cdecl

  naked call
  這是一個很少見的調用約定,一般程序設計者建議不要使用。編譯器不會給這種函數增加初始化和清理代碼,更特殊的是,你不能用return返回返回值,只能用插入匯編返回結果。這一般用于實模式驅動程序設計,假設定義一個求和的加法程序,可以定義為:

  __declspec(naked) int add(int a,int b)
  {
    __asm mov eax,a
    __asm add eax,b
    __asm ret
  }

  注意,這個函數沒有顯式的return返回值,返回通過修改eax寄存器實現,而且連退出函數的ret指令都必須顯式插入。上面代碼被翻譯成匯編以后變成:

  mov eax,[ebp+8]
  add eax,[ebp+12]
  ret 8

  注意這個修飾是和__stdcall及cdecl結合使用的,前面是它和cdecl結合使用的代碼,對于和stdcall結合的代碼,則變成:

  __declspec(naked) int __stdcall function(int a,int b)
  {
    __asm mov eax,a
    __asm add eax,b
    __asm ret 8    //注意后面的8
  }

  至于這種函數被調用,則和普通的cdecl及stdcall調用函數一致。

  函數調用約定導致的常見問題
  如果定義的約定和使用的約定不一致,則將導致堆棧被破壞,導致嚴重問題,下面是兩種常見的問題:

  函數原型聲明和函數體定義不一致
  DLL導入函數時聲明了不同的函數約定
  以后者為例,假設我們在dll種聲明了一種函數為:

  __declspec(dllexport) int func(int a,int b);//注意,這里沒有stdcall,使用的是cdecl
  使用時代碼為:

  typedef int (*WINAPI DLLFUNC)func(int a,int b);
  hLib = LoadLibrary(...);

  DLLFUNC func = (DLLFUNC)GetProcAddress(...)//這里修改了調用約定
  result = func(1,2);//導致錯誤

  由于調用者沒有理解WINAPI的含義錯誤的增加了這個修飾,上述代碼必然導致堆棧被破壞,MFC在編譯時插入的checkesp函數將告訴你,堆棧被破壞









 

Feedback

# re: 詳解函數調用約定  回復  更多評論   

2010-07-28 13:19 by 好看網
十分有道理 支持。
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            久久综合九色99| 欧美激情黄色片| 国产精品女人毛片| 欧美福利视频网站| 久久久av网站| 久久久久久欧美| 久久影院午夜片一区| 久久美女性网| 欧美激情在线有限公司| 欧美日韩三区| 国产精品午夜国产小视频| 国产视频一区在线观看| 一区二区在线看| 亚洲日本理论电影| 99在线观看免费视频精品观看| 亚洲美女免费精品视频在线观看| 夜夜嗨av一区二区三区中文字幕 | 久久综合狠狠综合久久综青草| 亚洲美女精品久久| 亚洲欧美日韩国产一区| 久久久久久亚洲综合影院红桃| 欧美大片网址| 正在播放亚洲| 久久五月天婷婷| 欧美色123| 136国产福利精品导航网址应用| 夜夜夜精品看看| 久久在线视频在线| 在线中文字幕日韩| 免费高清在线视频一区·| 国产精品国产福利国产秒拍| 在线观看亚洲视频啊啊啊啊| 在线亚洲精品福利网址导航| 久久性色av| 亚洲一区中文字幕在线观看| 女女同性精品视频| 国产一区二区主播在线| 亚洲亚洲精品在线观看| 嫩草国产精品入口| 亚洲欧美日韩专区| 欧美日韩国产综合视频在线观看| 国产真实乱子伦精品视频| 亚洲图片自拍偷拍| 亚洲国产精品999| 一区二区三区精密机械公司 | 欧美日韩在线电影| 亚洲第一二三四五区| 午夜精品视频在线观看| 亚洲人体一区| 免费日韩一区二区| 在线观看日韩| 久久久免费精品视频| 一本大道久久精品懂色aⅴ| 免费欧美在线| 激情成人av| 久久精品国产亚洲5555| 亚洲日韩成人| 欧美国产激情| 最新日韩av| 欧美高清视频一区二区三区在线观看 | 亚洲伊人一本大道中文字幕| 亚洲福利在线看| 久久这里有精品15一区二区三区| 国产一区二区三区黄| 久久黄色网页| 久久成人免费网| 亚洲福利小视频| 欧美不卡高清| 免费观看日韩av| 日韩视频一区二区三区在线播放免费观看 | 亚洲色诱最新| 国产精品v一区二区三区| 一区二区三区久久久| 日韩午夜av在线| 欧美日韩在线大尺度| 亚洲欧美成aⅴ人在线观看| 日韩视频永久免费| 国产精品国产三级国产专播品爱网 | 一本色道婷婷久久欧美| 亚洲精选91| 国产精品久久久久久久第一福利| 亚洲专区一区| 欧美一级理论片| 在线观看视频亚洲| 91久久午夜| 亚洲综合三区| 国产一区激情| 亚洲高清久久网| 欧美日韩国产成人在线91| 在线亚洲一区| 午夜久久福利| 亚洲黄色毛片| 一区二区三区四区五区精品| 国产精品视频一区二区高潮| 久久久久国色av免费看影院| 久久夜色精品| 亚洲天堂偷拍| 久久午夜精品一区二区| 99视频精品全部免费在线| 亚洲在线观看| 亚洲国产另类 国产精品国产免费| 91久久夜色精品国产九色| 国产精品一卡| 亚洲国产欧美在线人成| 国产精品捆绑调教| 免费久久99精品国产自| 欧美性猛交xxxx乱大交退制版| 久久久青草婷婷精品综合日韩| 欧美激情一区二区在线| 欧美一区二区在线视频| 欧美经典一区二区三区| 久久免费偷拍视频| 欧美性猛交99久久久久99按摩| 欧美高清在线视频观看不卡| 国产精品欧美日韩久久| 亚洲人成网站999久久久综合| 狠狠色狠色综合曰曰| 亚洲素人一区二区| 99在线精品视频| 久久综合精品国产一区二区三区| 午夜国产精品视频免费体验区| 男女精品视频| 久久久免费精品视频| 国产精品萝li| 亚洲另类春色国产| 亚洲国产高清在线观看视频| 久久成人资源| 久久久久国产精品一区二区| 国产精品日产欧美久久久久| 一区二区三区久久网| 一区二区精品在线| 欧美激情综合网| 亚洲国产女人aaa毛片在线| 尤物yw午夜国产精品视频| 欧美一区二区高清| 久久久99免费视频| 国产欧美一区二区精品婷婷| 亚洲午夜电影| 欧美一级片在线播放| 国产伦精品一区二区三区视频孕妇 | 欧美高清视频一区二区三区在线观看| 久久精品国产欧美亚洲人人爽| 国产欧美精品在线| 欧美一级视频免费在线观看| 欧美一级视频精品观看| 国产精品丝袜91| 欧美一二三视频| 激情久久婷婷| 久久综合图片| 欧美激情一二区| 亚洲精品一区二区三区婷婷月| 免费观看成人鲁鲁鲁鲁鲁视频| 欧美国产日韩视频| 亚洲毛片av| 欧美日韩国产一区精品一区 | 欧美国产亚洲另类动漫| 亚洲国产精品va在线看黑人| 夜夜爽夜夜爽精品视频| 国产精品人人做人人爽人人添| 午夜在线观看免费一区| 久久久久久一区二区| 亚洲国产黄色片| 欧美日韩中文另类| 久久超碰97中文字幕| 亚洲国产精品一区二区尤物区| 亚洲社区在线观看| 国产亚洲一区二区在线观看| 久热这里只精品99re8久| 亚洲精品午夜精品| 欧美在线视频播放| 亚洲精品美女在线| 国产精品亚洲产品| 媚黑女一区二区| 99精品久久久| 久久亚洲国产成人| 亚洲网站在线播放| 精品va天堂亚洲国产| 欧美日韩123| 久久九九全国免费精品观看| 亚洲国产一区二区三区a毛片| 亚洲欧美在线一区| 亚洲韩国日本中文字幕| 国产女优一区| 欧美激情综合在线| 久久精品国产精品亚洲综合| 亚洲精品护士| 蜜桃伊人久久| 欧美一区二区三区啪啪| 亚洲精品视频在线观看网站| 国产日韩精品电影| 欧美三级日本三级少妇99| 久久中文字幕导航| 欧美亚洲视频一区二区| 中文亚洲欧美| 亚洲人成网站在线观看播放| 免费成人性网站| 久久国产精品电影| 亚洲欧美日韩国产成人精品影院| 亚洲国产欧美不卡在线观看| 国产欧美精品xxxx另类|