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

posts - 29, comments - 16, trackbacks - 0, articles - 0
   :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

函數調用約定和堆棧 (轉)

Posted on 2009-02-15 10:43 王勇良 閱讀(1122) 評論(0)  編輯 收藏 引用 所屬分類: C++

    使用C/C++語言開發軟件的程序員經常碰到這樣的問題:有時候是程序編譯沒有問題,但是鏈接的時候總是報告函數不存在(經典的LNK 2001錯誤),有時候是程序編譯和鏈接都沒有錯誤,但是只要調用庫中的函數就會出現堆棧異常。這些現象通常是出現在CC++的代碼混合使用的情況下或 在C++程序中使用第三方的庫的情況下(不是用C++語言開發的),其實這都是函數調用約定(Calling Convention)和函數名修飾(Decorated Name)規則惹的禍。函數調用方式決定了函數參數入棧的順序,是由調用者函數還是被調用函數負責清除棧中的參數等問題,而函數名修飾規則決定了編譯器使 用何種名字修飾方式來區分不同的函數,如果函數之間的調用約定不匹配或者名字修飾不匹配就會產生以上的問題。本文分別對CC++這兩種編程語言的函數調 用約定和函數名修飾規則進行詳細的解釋,比較了它們的異同之處,并舉例說明了以上問題出現的原因。

函數調用約定(Calling Convention

    函數調用約定不僅決定了發生函數調用時函數參數的入棧順序,還決定了是由調用者函數還是被調用函數負責清除棧中的參數,還原堆棧。函數調用約定有很多方 式,除了常見的__cdecl__fastcall__stdcall之外,C++的編譯器還支持thiscall方式,不少C/C++編譯器還支持 naked call方式。這么多函數調用約定常常令許多程序員很迷惑,到底它們是怎么回事,都是在什么情況下使用呢?下面就分別介紹這幾種函數調用約定。


1.__cdecl

    編譯器的命令行參數是/Gd__cdecl方式是C/C++編譯器默認的函數調用約定,所有非C++成員函數和那些沒有用__stdcall __fastcall聲明的函數都默認是__cdecl方式,它使用C函數調用方式,函數參數按照從右向左的順序入棧,函數調用者負責清除棧中的參數,由 于每次函數調用都要由編譯器產生清除(還原)堆棧的代碼,所以使用__cdecl方式編譯的程序比使用__stdcall方式編譯的程序要大很多,但是 __cdecl調用方式是由函數調用者負責清除棧中的函數參數,所以這種方式支持可變參數,比如printfwindowsAPI wsprintf就是__cdecl調用方式。對于C函數,__cdecl方式的名字修飾約定是在函數名稱前添加一個下劃線;對于C++函數,除非特別使 用extern "C"C++函數使用不同的名字修飾方式。


2.__fastcall

    編譯器的命令行參數是/Gr__fastcall函數調用約定在可能的情況下使用寄存器傳遞參數,通常是前兩個 DWORD類型的參數或較小的參數使用ECXEDX寄存器傳遞,其余參數按照從右向左的順序入棧,被調用函數在返回之前負責清除棧中的參數。編譯器使用 兩個@修飾函數名字,后跟十進制數表示的函數參數列表大小,例如:@function_name@number。需要注意的是__fastcall函數調 用約定在不同的編譯器上可能有不同的實現,比如16位的編譯器和32位的編譯器,另外,在使用內嵌匯編代碼時,還要注意不能和編譯器使用的寄存器有沖突。


3.__stdcall
 
   
編譯器的命令行參數是/Gz__stdcallPascal程序的缺省調用方式,大多數WindowsAPI也是__stdcall調用約定。 __stdcall函數調用約定將函數參數從右向左入棧,除非使用指針或引用類型的參數,所有參數采用傳值方式傳遞,由被調用函數負責清除棧中的參數。對 于C函數,__stdcall的名稱修飾方式是在函數名字前添加下劃線,在函數名字后添加@和函數參數的大小,例如:_functionname@number

4.thiscall

    thiscall只用在C++成員函數的調用,函數參數按照從右向左的順序入棧,類實例的this指針通過ECX寄存器傳遞。需要注意的是thiscall不是C++的關鍵字,不能使用thiscall聲明函數,它只能由編譯器使用。

5.naked call

    采用前面幾種函數調用約定的函數,編譯器會在必要的時候自動在函數開始添加保存ESIEDIEBXEBP寄存器的代碼,在退出函數時恢復這些寄存器 的內容,使用naked call方式聲明的函數不會添加這樣的代碼,這也就是為什么稱其為naked的原因吧。naked  call不是類型修飾符,故必須和_declspec共同使用。

    VC的編譯環境默認是使用__cdecl調用約定,也可以在編譯環境的Project Setting...菜單-》C/C++ =》Code  Generation項選擇設置函數調用約定。也可以直接在函數聲明前添加關鍵字__stdcall__cdecl__fastcall等單獨確定函 數的調用方式。在Windows系統上開發軟件常用到WINAPI宏,它可以根據編譯設置翻譯成適當的函數調用約定,在WIN32中,它被定義為 __stdcall 

 

函數名字修飾(Decorated Name)方式

    函數的名字修飾(Decorated Name)就是編譯器在編譯期間創建的一個字符串,用來指明函數的定義或原型。LINK程序或其他工具有時需要指定函數的名字修飾來定位函數的正確位置。 多數情況下程序員并不需要知道函數的名字修飾,LINK程序或其他工具會自動區分他們。當然,在某些情況下需要指定函數的名字修飾,例如在C++程序中, 為了讓LINK程序或其他工具能夠匹配到正確的函數名字,就必須為重載函數和一些特殊的函數(如構造函數和析構函數)指定名字裝飾。另一種需要指定函數的 名字修飾的情況是在匯編程序中調用CC++的函數。如果函數名字,調用約定,返回值類型或函數參數有任何改變,原來的名字修飾就不再有效,必須指定新的 名字修飾。CC++程序的函數在內部使用不同的名字修飾方式,下面將分別介紹這兩種方式。

1. C編譯器的函數名修飾規則

    對于__stdcall調用約定,編譯器和鏈接器會在輸出函數名前加上一個下劃線前綴,函數名后面加上一個“@”符號和其參數的字節數,例如_functionname@number__cdecl調用約定僅在輸出函數名前加上一個下劃線前綴,例如_functionname__fastcall調用約定在輸出函數名前加上一個“@”符號,后面也是一個“@”符號和其參數的字節數,例如@functionname@number   
 
2. C++
編譯器的函數名修飾規則

    C++的函數名修飾規則有些復雜,但是信息更充分,通過分析修飾名不僅能夠知道函數的調用方式,返回值類型,參數個數甚至參數類型。不管 __cdecl__fastcall還是__stdcall調用方式,函數修飾都是以一個“?”開始,后面緊跟函數的名字,再后面是參數表的開始標識和 按照參數類型代號拼出的參數表。對于__stdcall方式,參數表的開始標識是“@@YG,對于__cdecl方式則是“@@YA,對于__fastcall方式則是“@@YI。參數表的拼寫代號如下所示:
X--void   
D--char   
E--unsigned char   
F--short   
H--int   
I--unsigned int   
J--long   
K--unsigned long
DWORD
M--float   
N--double   
_N--bool
U--struct
....
指 針的方式有些特別,用PA表示指針,用PB表示const類型的指針。后面的代號表明指針類型,如果相同類型的指針連續出現,以0”代替,一個0”代 表一次重復。U表示結構類型,通常后跟結構體的類型名,用“@@”表示結構類型名的結束。函數的返回值不作特殊處理,它的描述方式和函數參數一樣,緊跟著 參數表的開始標志,也就是說,函數參數表的第一項實際上是表示函數的返回值類型。參數表后以“@Z標識整個名字的結束,如果該函數無參數,則以“Z”標識結束。下面舉兩個例子,假如有以下函數聲明:

int Function1(char *var1,unsigned long);

其函數修飾名為“?Function1@@YGHPADK@Z,而對于函數聲明:

void Function2();

其函數修飾名則為“?Function2@@YGXXZ

 

    對于C++的類成員函數(其調用方式是thiscall),函數的名字修飾與非成員的C++函數稍有不同,首先就是在函數名字和參數表之間插入以“@”字符引導的類名;其次是參數表的開始標識不同,公有(public)成員函數的標識是“@@QAE”,保護(protected)成員函數的標識是“@@IAE”,私有(private)成員函數的標識是“@@AAE,如果函數聲明使用了const關鍵字,則相應的標識應分別為“@@QBE“@@IBE“@@ABE。如果參數類型是類實例的引用,則使用“AAV1”,對于const類型的引用,則使用“ABV1”。下面就以類CTest為例說明C++成員函數的名字修飾規則:

class CTest
{
......
private:
    void Function(int);
protected:
    void CopyInfo(const CTest &src);
public:
    long DrawText(HDC hdc, long pos, const TCHAR* text, RGBQUAD color, BYTE bUnder, bool bSet);
    long InsightClass(DWORD dwClass) const;
......
};

對于成員函數Function,其函數修飾名為“?Function@CTest@@AAEXH@Z,字符串“@@AAE表示這是一個私有函數。成員函數CopyInfo只有一個參數,是對類CTestconst引用參數,其函數修飾名為“?CopyInfo@CTest@@IAEXABV1@@Z DrawText是一個比較復雜的函數聲明,不僅有字符串參數,還有結構體參數和HDC句柄參數,需要指出的是HDC實際上是一個HDC__結構類型的指 針,這個參數的表示就是“PAUHDC__@@”,其完整的函數修飾名為“?DrawText@CTest@@QAEJPAUHDC__@@JPBDUtagRGBQUAD@@E_N@ZInsightClass是一個共有的const函數,它的成員函數標識是“@@QBE,完整的修飾名就是“?InsightClass@CTest@@QBEJK@Z

無論是C函數名修飾方式還是C++函數名修飾方式均不改變輸出函數名中的字符大小寫,這和PASCAL調用約定不同,PASCAL約定輸出的函數名無任何修飾且全部大寫。

3.查看函數的名字修飾

    有兩種方式可以檢查你的程序中的函數的名字修飾:使用編譯輸出列表或使用Dumpbin工具。使用/FAc/FAs/FAcs命令行參數可以讓編譯器 輸出函數或變量名字列表。使用dumpbin.exe /SYMBOLS命令也可以獲得obj文件或lib文件中的函數或變量名字列表。此外,還可以使用 undname.exe 將修飾名轉換為未修飾形式。

 

函數調用約定和名字修飾規則不匹配引起的常見問題

    函數調用時如果出現堆棧異常,十有八九是由于函數調用約定不匹配引起的。比如動態鏈接庫a有以下導出函數:

long MakeFun(long lFun);

動態庫生成的時候采用的函數調用約定是__stdcall,所以編譯生成的a.dll中函數MakeFun的調用約 定是_stdcall,也就是函數調用時參數從右向左入棧,函數返回時自己還原堆棧。現在某個程序模塊b要引用a中的MakeFunba一樣使用 C++方式編譯,只是b模塊的函數調用方式是__cdecl,由于b包含了a提供的頭文件中MakeFun函數聲明,所以MakeFunb模塊中被其它 調用MakeFun的函數認為是__cdecl調用方式,b模塊中的這些函數在調用完MakeFun當然要幫著恢復堆棧啦,可是MakeFun已經在結束 時自己恢復了堆棧,b模塊中的函數這樣多此一舉就引起了棧指針錯誤,從而引發堆棧異常。宏觀上的現象就是函數調用沒有問題(因為參數傳遞順序是一樣 的),MakeFun也完成了自己的功能,只是函數返回后引發錯誤。解決的方法也很簡單,只要保證兩個模塊的在編譯時設置相同的函數調用約定就行了。

 

    在了解了函數調用約定和函數的名修飾規則之后,再來看在C++程序中使用C語言編譯的庫時經常出現的LNK 2001錯誤就很簡單了。還以上面例子的兩個模塊為例,這一次兩個模塊在編譯的時候都采用__stdcall調用約定,但是a.dll使用C語言的語法編 譯的(C語言方式),所以a.dll的載入庫a.libMakeFun函數的名字修飾就是“_MakeFun@4b包含了a提供的頭文件中MakeFun函數聲明,但是由于b采用的是C++語言編譯,所以MakeFunb模塊中被按照C++的名字修飾規則命名為“?MakeFun@@YGJJ@Z,編譯過程相安無事,鏈接程序時c++的鏈接器就到a.lib中去找“?MakeFun@@YGJJ@Z,但是a.lib中只有“_MakeFun@4,沒有“?MakeFun@@YGJJ@Z,于是鏈接器就報告:

error LNK2001: unresolved external symbol ?MakeFun@@YGJJ@Z

解決的方法和簡單,就是要讓b模塊知道這個函數是C語言編譯的,extern "C"可以做到這一點。一個采用C語言編譯的庫應該考慮到使用這個庫的程序可能是C++程序(使用C++編譯器),所以在設計頭文件時應該注意這一點。通常應該這樣聲明頭文件:

#ifdef _cplusplus
extern "C" {
#endif

long MakeFun(long lFun);

#ifdef _cplusplus
}
#endif

這樣C++的編譯器就知道MakeFun的修飾名是“_MakeFun@4,就不會有鏈接錯誤了。

    許多人不明白,為什么我使用的編譯器都是VC的編譯器還會產生“error LNK2001”錯誤?其實,VC的編譯器會根據源文件的擴展名選擇編譯方式,如果文件的擴展名是“.C”,編譯器會采用C的語法編譯,如果擴展名是 “.cpp”,編譯器會使用C++的語法編譯程序,所以,最好的方法就是使用extern "C"

 

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            夜夜爽夜夜爽精品视频| 久热这里只精品99re8久| 久久高清福利视频| 亚洲女性裸体视频| 亚洲小说欧美另类婷婷| 亚洲色诱最新| 午夜免费日韩视频| 久久精品免视看| 免费在线亚洲欧美| 欧美成人日韩| 亚洲精品国产精品国产自| 亚洲欧洲综合另类| 一本到高清视频免费精品| 国产一区二区久久久| 国产视频综合在线| 国产综合色产在线精品| 在线观看亚洲视频| 日韩午夜av电影| 亚洲专区免费| 久久天天躁狠狠躁夜夜爽蜜月 | 国产日韩欧美一区二区三区在线观看| 国产精品日韩精品欧美精品| 国产视频在线观看一区二区三区| 亚洲电影中文字幕| 亚洲在线观看视频| 免费中文字幕日韩欧美| 一级日韩一区在线观看| 久久精品国产一区二区电影| 欧美日韩国产限制| 亚洲电影第1页| 西西人体一区二区| 每日更新成人在线视频| 中文一区字幕| 欧美 日韩 国产一区二区在线视频| 欧美日韩一区成人| 红桃视频一区| 亚洲欧美日韩中文视频| 亚洲国产99精品国自产| 亚洲福利在线观看| 亚洲欧美日韩另类| 欧美激情精品久久久久久久变态 | 国产一区在线播放| 日韩午夜在线| 久久精视频免费在线久久完整在线看| 亚洲精品1区| 欧美一区日本一区韩国一区| 欧美日韩国产成人在线免费| 亚洲高清久久网| 久久九九久精品国产免费直播| 日韩视频中午一区| 久久亚洲国产精品日日av夜夜| 国产精品国产三级国产aⅴ无密码| 欧美一区二区三区免费看 | 久久人人爽国产| 国产情侣一区| 亚洲一区二区三区免费在线观看| 久久久久亚洲综合| 国产精品乱子久久久久| 久久精品国产99精品国产亚洲性色 | 午夜精彩视频在线观看不卡 | 欧美国产欧美亚洲国产日韩mv天天看完整 | 欧美一区二区三区四区高清| 欧美日韩综合一区| 一道本一区二区| 99热在线精品观看| 欧美午夜精品久久久久久人妖| 亚洲视频播放| 亚洲一区二区精品在线| 国产精品三级久久久久久电影| 午夜精品国产精品大乳美女| 欧美国产极速在线| 欧美a级大片| 一本久道久久久| 99热在线精品观看| 国产欧美精品一区二区三区介绍| 欧美在线观看网站| 久久精品视频免费播放| 亚洲激情视频在线观看| 亚洲精品国产精品久久清纯直播| 欧美久久久久中文字幕| 亚洲一二区在线| 欧美一级大片在线观看| 在线观看亚洲精品| 亚洲免费观看在线视频| 国产精品久久久亚洲一区| 久久国产精品一区二区三区四区| 久久久亚洲综合| 一区二区欧美日韩视频| 午夜久久黄色| 亚洲人在线视频| 久久亚洲综合网| 欧美日产一区二区三区在线观看| 亚欧美中日韩视频| 欧美视频日韩| 久久爱另类一区二区小说| 久久精品亚洲一区二区| 欧美香蕉大胸在线视频观看| 欧美激情一区二区三级高清视频| 欧美午夜精品| 欧美一区二区国产| 久久久久久久国产| 久久久精品国产一区二区三区 | 国产丝袜美腿一区二区三区| 嫩草国产精品入口| 欧美视频在线免费| 欧美.www| 国产欧美亚洲精品| 亚洲伦理久久| 亚洲电影免费观看高清| 亚洲一区精品在线| 亚洲激情在线视频| 久久成人一区二区| 亚洲午夜在线视频| 欧美顶级少妇做爰| 久久嫩草精品久久久久| 国产精品成人观看视频免费| 欧美~级网站不卡| 国产精品视屏| 巨乳诱惑日韩免费av| 日韩亚洲在线观看| 亚洲电影专区| 久久久久久久999精品视频| 亚洲欧美成人在线| 欧美日韩一级视频| 亚洲日本乱码在线观看| 在线日韩中文字幕| 欧美综合国产| 久久精品国产亚洲一区二区三区| 欧美视频一区在线观看| 亚洲高清久久久| 在线日韩中文| 蜜桃av久久久亚洲精品| 久久午夜精品| 国产真实乱偷精品视频免| 亚洲欧美成人| 久久er精品视频| 国产婷婷色一区二区三区四区| 亚洲自拍偷拍麻豆| 先锋影音久久| 国产亚洲观看| 欧美一区二区在线播放| 久久精品99国产精品酒店日本| 国产精品视频久久| 午夜精品av| 久久只有精品| 欧美成人精品一区二区| 亚洲国产婷婷香蕉久久久久久| 久久久久久久综合日本| 美日韩精品视频| 一区在线免费观看| 久久久精品午夜少妇| 欧美 日韩 国产 一区| 国产色产综合产在线视频| 亚洲女ⅴideoshd黑人| 欧美中文字幕不卡| 曰韩精品一区二区| 欧美高清你懂得| 99在线精品视频| 欧美中文字幕不卡| 亚洲国产日韩美| 欧美视频中文在线看| 午夜久久久久久久久久一区二区| 久久尤物视频| 99精品99| 国产欧美日韩一级| 久久久久久亚洲精品中文字幕 | 欧美日韩国产页| 亚洲欧美精品中文字幕在线| 另类人畜视频在线| 一区二区激情| 国内精品美女在线观看| 欧美经典一区二区| 西西裸体人体做爰大胆久久久| 免费人成精品欧美精品| 亚洲天堂av图片| 国内精品一区二区| 欧美日本一区| 欧美一区二区播放| 亚洲开发第一视频在线播放| 久久九九99| 亚洲与欧洲av电影| 亚洲日本激情| 国产欧美日韩视频一区二区三区| 久久中文字幕一区| 亚洲欧美韩国| 亚洲理伦电影| 亚洲午夜精品久久| 樱花yy私人影院亚洲| 欧美日韩一区综合| 另类综合日韩欧美亚洲| 亚洲欧美成人一区二区在线电影 | 欧美成人精品1314www| 亚洲在线观看免费| 99视频精品免费观看| 极品尤物久久久av免费看| 国产精品久久久久久影院8一贰佰| 免费视频一区| 久久躁日日躁aaaaxxxx| 新片速递亚洲合集欧美合集| 制服丝袜激情欧洲亚洲|