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

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

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

Posted on 2009-02-15 10:43 王勇良 閱讀(1119) 評論(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>
            久久久久在线| 99精品久久| 中文精品视频| 亚洲欧美综合精品久久成人| 在线观看视频免费一区二区三区| 亚洲精品国产系列| 99综合电影在线视频| 亚洲欧美日韩精品在线| 欧美一区二区日韩一区二区| 亚洲国产国产亚洲一二三| 欧美精品福利| 日韩视频不卡中文| 日韩一区二区久久| 久久久噜噜噜久久中文字免| 欧美日本成人| 欧美精品999| 欧美日韩国产成人在线| 久久久人成影片一区二区三区观看 | 在线亚洲美日韩| 国产麻豆成人精品| 欧美午夜视频| 久久er精品视频| 国产欧美91| 国内一区二区在线视频观看| 国产在线视频不卡二| 国产欧美一区二区三区在线老狼| 久久蜜桃精品| 亚洲欧美99| 国产欧美一区视频| 亚洲一级片在线观看| 欧美一区激情| 亚洲一区二区三区涩| 国产美女精品免费电影| 一区二区在线视频观看| 欧美大片专区| 欧美在线视频观看| 欧美激情综合五月色丁香小说| 亚洲欧美日韩国产综合在线| 亚洲经典视频在线观看| 亚洲麻豆视频| 国产精品午夜春色av| 久久频这里精品99香蕉| 日韩一级黄色片| 久久精品国产清高在天天线| 久久不见久久见免费视频1| 一本色道久久综合亚洲精品婷婷 | 妖精视频成人观看www| 欧美色欧美亚洲另类二区| 国产精品99一区二区| 亚洲欧美欧美一区二区三区| 美女91精品| 一本色道综合亚洲| 亚洲高清av| 欧美久久久久久| 欧美激情精品久久久久久免费印度| 欧美三级欧美一级| 久久视频在线视频| 欧美jizz19性欧美| 国产一区二区三区在线观看免费视频| 在线一区二区日韩| 久久久www| 国产午夜亚洲精品羞羞网站 | 亚洲成人直播| 欧美影视一区| 欧美精品导航| 国产精品永久免费在线| 欧美成人a视频| 亚洲国产成人porn| 久久国产一区二区三区| 国产精品欧美一区喷水| 精品999网站| 亚洲欧美中文字幕| 欧美在线视频一区| 久久综合久久综合九色| 韩国av一区二区三区四区| 亚洲精品免费一区二区三区| 欧美日韩日本网| 一区二区三区导航| 亚洲一级黄色av| 国模精品娜娜一二三区| 午夜影院日韩| 亚洲福利国产精品| 激情婷婷久久| 老司机午夜免费精品视频| 亚洲国产精品久久久久| 欧美成人在线网站| 国产精品久久久久一区二区三区共 | 久久丁香综合五月国产三级网站| 国产午夜精品视频| 亚洲精品久久久久| 国产精品美腿一区在线看| 99国产精品视频免费观看| 免费观看日韩| 夜夜嗨av一区二区三区四季av| 欧美日韩在线播放三区四区| 欧美与欧洲交xxxx免费观看| 国产精品久久午夜夜伦鲁鲁| 亚洲国产欧美另类丝袜| 欧美日韩一区二区精品| 亚洲一区精彩视频| 欧美一区二区三区播放老司机| 亚洲人成网在线播放| 国内精品视频一区| 久久国产精品免费一区| 99国产精品99久久久久久粉嫩| 亚洲国产黄色| 亚洲网站视频福利| 久久九九电影| 久久久久.com| 99国产精品国产精品毛片| 欧美日韩一卡| 日韩视频不卡| 亚洲一区二区三区中文字幕| 欧美黑人在线播放| 久久成人人人人精品欧| 久久成人18免费观看| 久久精品视频在线看| 日韩一级精品| 男男成人高潮片免费网站| 日韩一区二区免费看| 欧美高清在线观看| 亚洲一区3d动漫同人无遮挡| 亚洲综合成人婷婷小说| 欧美激情亚洲视频| 免费在线欧美视频| 久久久久亚洲综合| 久久免费视频网| 一本久久精品一区二区| 亚洲黑丝在线| 亚洲高清资源| 久热精品视频在线观看一区| 国产精品一区久久久久| 欧美r片在线| 免费看精品久久片| 欧美一区二区三区免费看| 亚洲高清免费| 99视频一区二区| 亚洲中午字幕| 国产精品99久久久久久有的能看 | 欧美在线啊v| 亚洲黄色成人久久久| 欧美激情在线播放| 欧美国产日本在线| 欧美激情在线播放| 久久久视频精品| 在线观看成人av| 欧美伊人精品成人久久综合97| 亚洲综合色噜噜狠狠| 亚洲欧美影音先锋| 久久嫩草精品久久久久| 亚洲男女毛片无遮挡| 香港久久久电影| 中文有码久久| 激情一区二区三区| 欧美凹凸一区二区三区视频| 亚洲国产精品一区二区www在线| 老司机成人网| 亚洲高清影视| 欧美大片专区| 一区二区免费在线播放| 免费成人美女女| 亚洲欧美www| 亚洲欧美综合国产精品一区| 欧美伦理视频网站| 99国产精品久久久久久久| 在线亚洲欧美专区二区| 欧美中文字幕视频在线观看| 亚洲一区二区免费看| 国产精品一区二区你懂得| 久久精品日韩欧美| 欧美国产先锋| 亚洲欧洲精品成人久久奇米网| 欧美高清免费| 亚洲精品乱码| 亚洲欧美日韩专区| 噜噜噜在线观看免费视频日韩| 激情av一区| 亚洲尤物视频在线| 性色av一区二区三区在线观看 | 99天天综合性| 玖玖视频精品| 亚洲高清精品中出| 亚洲性感激情| 欧美成人有码| 国产综合精品一区| 午夜精品免费| 久久成人18免费网站| 久久女同精品一区二区| 韩日成人av| 另类av导航| 另类春色校园亚洲| 亚洲在线电影| 午夜天堂精品久久久久| 中日韩美女免费视频网站在线观看 | 米奇777超碰欧美日韩亚洲| 久久久久国产精品人| 亚洲福利在线视频| 亚洲高清久久| 欧美成人自拍| 久久琪琪电影院|