• <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>
            Own Zone
            Lotto
            posts - 3,  comments - 3,  trackbacks - 0

            在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
            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調用 0401C1D 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調用函數一致。

            函數調用約定導致的常見問題

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

            1. 函數原型聲明和函數體定義不一致
            2. 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函數將告訴你,堆棧被破壞了。

            posted on 2009-03-11 11:11 Lotto 閱讀(86) 評論(0)  編輯 收藏 引用
            Locations of visitors to this page

            <2025年5月>
            27282930123
            45678910
            11121314151617
            18192021222324
            25262728293031
            1234567

            常用鏈接

            留言簿(1)

            隨筆檔案

            文章檔案

            相冊

            搜索

            •  

            最新評論

            閱讀排行榜

            評論排行榜

            久久精品卫校国产小美女| 人人狠狠综合久久亚洲婷婷| 久久国产免费直播| 亚洲精品乱码久久久久久蜜桃| 青青久久精品国产免费看| 久久久久高潮综合影院| 国产精品久久国产精品99盘| 久久久久无码精品| 天天躁日日躁狠狠久久| 国产精品欧美久久久久天天影视| 久久久人妻精品无码一区| 伊人久久精品无码av一区| 久久亚洲国产欧洲精品一| 久久天天躁夜夜躁狠狠| 久久精品视频网| 日产精品99久久久久久| 99热精品久久只有精品| 蜜臀久久99精品久久久久久小说| 久久精品成人免费观看97| 精品久久久久久久无码| 久久国产AVJUST麻豆| 91超碰碰碰碰久久久久久综合| 浪潮AV色综合久久天堂| 中文字幕精品久久| 亚洲精品视频久久久| 狠狠色综合网站久久久久久久| 久久久久久九九99精品| 久久精品一本到99热免费| 无码人妻久久一区二区三区蜜桃| 国产精品久久久久乳精品爆| 久久91亚洲人成电影网站| 精品久久久久久无码中文字幕一区 | 无码久久精品国产亚洲Av影片| 久久99精品国产麻豆蜜芽| 51久久夜色精品国产| 嫩草影院久久国产精品| 久久九九有精品国产23百花影院| 久久久久99精品成人片欧美| 欧美喷潮久久久XXXXx| 色狠狠久久AV五月综合| 成人免费网站久久久|