C/C++函數呼叫慣例與函數名稱修飾規則探討
作者:星軌(oRbIt)
使用C/C++語言開發軟體的程式員經常碰到這樣的問題:有時候是程式編譯沒有問題,但是連結的時候總是報告函數不存在(經典的LNK 2001錯誤),有時候是程式編譯和連結都沒有錯誤,但是只要調用庫中的函數就會出現堆棧異常。這些現象通常是出現在C和C++的代碼混合使用的情況下或在C++程式中使用第三方的庫的情況下(不是用C++語言開發的),其實這都是函數呼叫慣例(Calling Convention)和函數名修飾(Decorated Name)規則惹的禍。函數調用方式決定了函數參數入棧的順序,是由調用者函數還是被調用函數負責清除棧中的參數等問題,而函數名修飾規則決定了編譯器使用何種名字修飾方式來區分不同的函數,如果函數之間的呼叫慣例不匹配或者名字修飾不匹配就會產生以上的問題。本文分別對C和C++這兩種程式設計語言的函數呼叫慣例和函數名修飾規則進行詳細的解釋,比較了它們的異同之處,並舉例說明了以上問題出現的原因。
函數呼叫慣例(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調用方式是由函數調用者負責清除棧中的函數參數,所以這種方式支援可變參數,比如printf和windows的API wsprintf就是__cdecl調用方式。對於C函數,__cdecl方式的名字修飾約定是在函數名稱前添加一個底線;對於C++函數,除非特別使用extern "C",C++函數使用不同的名字修飾方式。
2.__fastcall
編譯器的命令列參數是/Gr。__fastcall函數呼叫慣例在可能的情況下使用寄存器傳遞參數,通常是前兩個 DWORD類型的參數或較小的參數使用ECX和EDX寄存器傳遞,其餘參數按照從右向左的順序入棧,被調用函數在返回之前負責清除棧中的參數。編譯器使用兩個@修飾函數名字,後跟十進位數表示的函數參數列表大小,例如:@function_name@number。需要注意的是__fastcall函數呼叫慣例在不同的編譯器上可能有不同的實現,比如16位的編譯器和32位的編譯器,另外,在使用內嵌彙編代碼時,還要注意不能和編譯器使用的寄存器有衝突。
3.__stdcall
編譯器的命令列參數是/Gz,__stdcall是Pascal程式的預設調用方式,大多數Windows的API也是__stdcall呼叫慣例。__stdcall函數呼叫慣例將函數參數從右向左入棧,除非使用指標或參考型別的參數,所有參數採用傳值方式傳遞,由被調用函數負責清除棧中的參數。對於C函數,__stdcall的名稱修飾方式是在函數名字前添加底線,在函數名字後添加@和函數參數的大小,例如:_functionname@number
4.thiscall
thiscall只用在C++成員函數的調用,函數參數按照從右向左的順序入棧,類執行個體的this指標通過ECX寄存器傳遞。需要注意的是thiscall不是C++的關鍵字,不能使用thiscall聲明函數,它只能由編譯器使用。
5.naked call
採用前面幾種函數呼叫慣例的函數,編譯器會在必要的時候自動在函數開始添加儲存ESI,EDI,EBX,EBP寄存器的代碼,在退出函數時恢複這些寄存器的內容,使用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程式或其他工具能夠匹配到正確的函數名字,就必須為重載函數和一些特殊的函數(如建構函式和解構函式)指定名字裝飾。另一種需要指定函數的名字修飾的情況是在組譯工具中調用C或C++的函數。如果函數名字,呼叫慣例,傳回值類型或函數參數有任何改變,原來的名字修飾就不再有效,必須指定新的名字修飾。C和C++程式的函數在內部使用不同的名字修飾方式,下面將分別介紹這兩種方式。
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只有一個參數,是對類CTest的const引用參數,其函數修飾名為“?CopyInfo@CTest@@IAEXABV1@@Z”。DrawText是一個比較複雜的函式宣告,不僅有字串參數,還有結構體參數和HDC控制代碼參數,需要指出的是HDC實際上是一個HDC__結構類型的指標,這個參數的表示就是“PAUHDC__@@”,其完整的函數修飾名為“?DrawText@CTest@@QAEJPAUHDC__@@JPBDUtagRGBQUAD@@E_N@Z”。InsightClass是一個共有的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中的MakeFun,b和a一樣使用C++方式編譯,只是b模組的函數調用方式是__cdecl,由於b包含了a提供的標頭檔中MakeFun函式宣告,所以MakeFun在b模組中被其它調用MakeFun的函數認為是__cdecl調用方式,b模組中的這些函數在調用完MakeFun當然要幫著恢複堆棧啦,可是MakeFun已經在結束時自己恢複了堆棧,b模組中的函數這樣多此一舉就引起了棧指標錯誤,從而引發堆棧異常。宏觀上的現象就是函數調用沒有問題(因為參數行程順序是一樣的),MakeFun也完成了自己的功能,只是函數返回後引發錯誤。解決的方法也很簡單,只要保證兩個模組的在編譯時間設定相同的函數呼叫慣例就行了。
在瞭解了函數呼叫慣例和函數的名修飾規則之後,再來看在C++程式中使用C語言編譯的庫時經常出現的LNK 2001錯誤就很簡單了。還以上面例子的兩個模組為例,這一次兩個模組在編譯的時候都採用__stdcall呼叫慣例,但是a.dll使用C語言的文法編譯的(C語言方式),所以a.dll的載入庫a.lib中MakeFun函數的名字修飾就是“_MakeFun@4”。b包含了a提供的標頭檔中MakeFun函式宣告,但是由於b採用的是C++語言編譯,所以MakeFun在b模組中被按照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"。