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

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久久精品 | 国产一区二区三区免费观看| 欧美一区二区久久久| 久久er精品视频| 亚洲日本欧美在线| 9国产精品视频| 国产一区二区三区的电影| 欧美成人国产| 欧美日韩日本网| 久久久久久香蕉网| 久久久亚洲影院你懂的| 久久亚洲欧美国产精品乐播| 老司机精品导航| 亚洲深夜影院| 欧美在线观看一区| 99精品久久免费看蜜臀剧情介绍| 亚洲视频999| 亚洲经典视频在线观看| 亚洲一区二区在线| 亚洲欧洲在线视频| 午夜在线精品| 中日韩视频在线观看| 久久精品一区二区三区不卡| 日韩视频免费| 久久久久综合网| 亚洲欧美国产毛片在线| 麻豆国产精品777777在线| 亚洲一区二区三区四区五区黄 | 99精品黄色片免费大全| 韩国精品主播一区二区在线观看| 亚洲人午夜精品免费| 国产精品国产三级国产aⅴ浪潮| 久久久久久国产精品mv| 欧美日韩妖精视频| 亚洲成人在线视频播放| 国产一区二区三区无遮挡| 亚洲美女精品一区| 亚洲经典自拍| 久久久久久久综合狠狠综合| 亚洲欧洲av一区二区| 欧美日韩国产在线观看| 欧美激情精品久久久久| 黄色精品一区二区| 亚洲欧美综合一区| 午夜国产精品视频免费体验区| 欧美电影在线观看完整版| 美女精品国产| 狠狠色狠狠色综合日日91app| 亚洲亚洲精品在线观看| 一区二区国产精品| 欧美日本亚洲| 亚洲精品中文字幕在线观看| 亚洲啪啪91| 欧美va日韩va| 亚洲激情视频在线| 亚洲乱码国产乱码精品精可以看 | 亚洲清纯自拍| 亚洲美女av黄| 欧美日韩在线播放一区| 日韩午夜激情电影| 亚洲影视在线播放| 国产精品色网| 性久久久久久久久| 久久午夜视频| 亚洲人成小说网站色在线| 老鸭窝91久久精品色噜噜导演| 欧美成人久久| 一本久道久久综合狠狠爱| 欧美日本三区| 午夜精品久久久久久久99热浪潮| 欧美亚洲系列| 在线观看欧美一区| 欧美成人一区二区三区在线观看| 亚洲国产精品久久久久秋霞影院| 亚洲伦理中文字幕| 亚洲美女91| 136国产福利精品导航网址应用| 久久久欧美精品sm网站| 亚洲高清视频中文字幕| 一区二区三区四区国产精品| 国产精品免费网站| 久久狠狠亚洲综合| 91久久精品国产91久久性色tv | 国产毛片精品视频| 久久女同精品一区二区| 亚洲精品护士| 欧美中日韩免费视频| 亚洲国产成人精品视频| 欧美日韩亚洲一区二区三区在线观看 | 欧美xx69| 亚洲视频观看| 免费看黄裸体一级大秀欧美| 亚洲人成小说网站色在线| 国产精品久久99| 久久婷婷久久| 亚洲一区二区欧美| 欧美二区在线| 午夜一级在线看亚洲| 亚洲第一页在线| 国产精品久久久91| 老司机一区二区| 午夜在线观看免费一区| 亚洲欧洲一区二区在线播放| 欧美一区二区视频97| 亚洲精品欧美极品| 国内不卡一区二区三区| 欧美日韩午夜视频在线观看| 久久精品国产91精品亚洲| 亚洲每日在线| 最新中文字幕一区二区三区| 久久九九国产精品| 亚洲欧美日韩国产另类专区| 亚洲欧洲日产国产综合网| 国产一区二区精品| 国产精品美女久久久久久2018| 欧美mv日韩mv国产网站app| 欧美制服丝袜| 亚洲主播在线播放| 日韩视频一区二区在线观看 | 一区二区三区你懂的| 亚洲欧洲一区二区三区| 黄色成人av在线| 国产日韩一区二区三区在线| 国产精品高潮呻吟| 国产精品v日韩精品| 欧美精品福利视频| 欧美大片va欧美在线播放| 老**午夜毛片一区二区三区| 午夜精品一区二区三区四区| 亚洲视频在线观看| 亚洲天堂av在线免费| 亚洲开发第一视频在线播放| 欧美激情二区三区| 欧美激情女人20p| 欧美高清你懂得| 欧美黄色免费| 亚洲激情网站| aa级大片欧美| 一区二区三区鲁丝不卡| 亚洲色图在线视频| 亚洲一区二区高清| 午夜精品国产精品大乳美女| 亚洲视频日本| 国产亚洲免费的视频看| 国产午夜精品久久久久久免费视| 国产麻豆精品在线观看| 国产午夜精品久久久久久久| 精品91视频| 亚洲国产精品视频一区| 亚洲精品久久久久| 亚洲视频自拍偷拍| 欧美一区二区三区另类| 久久精品日韩| 欧美激情第9页| 一区二区三区**美女毛片| 亚洲在线免费| 久久久精品五月天| 欧美精品成人91久久久久久久| 国产精品v欧美精品v日韩精品| 国产精品爽爽ⅴa在线观看| 国产一本一道久久香蕉| 亚洲高清免费在线| 一区二区三区视频在线| 久久精品噜噜噜成人av农村| 欧美v国产在线一区二区三区| 亚洲经典一区| 午夜精品久久久久久久99水蜜桃 | 久久夜色精品国产亚洲aⅴ| 免费在线观看一区二区| 欧美新色视频| 曰本成人黄色| 亚洲尤物在线| 欧美wwwwww| 亚洲在线网站| 欧美激情一区二区三级高清视频 | 久久一区二区三区国产精品| 欧美精品福利| 在线观看日韩av先锋影音电影院 | 国产亚洲一区二区三区在线观看 | 免费久久99精品国产| 一区二区电影免费在线观看| 久久精品亚洲一区| 欧美性大战xxxxx久久久| 亚洲高清激情| 久久久久久久欧美精品| 一区二区三区欧美在线观看| 久久天堂精品| 国产亚洲一二三区| 午夜精品影院| a91a精品视频在线观看| 能在线观看的日韩av| 红桃视频亚洲| 久久精品人人| 午夜精品在线视频| 国产精品亚洲成人|