DLL斷點調試

通常來講調試DLL是把DLL工程和exe工程放到一個解決方案裏。若是不放到一個解決方案裏，那二者的輸出目錄要一致，屬性-鏈接器-常規-輸出目錄。保證dll，dll的pdb，exe，exe的pdb在一個文件夾內。

 

dll 導出函數名的那些事

關鍵字：　VC++ 　DLL  導出函數　

常用VC6的Dependency查看DLL導出函數的名字，會發現有DLL導出函數的名字有時大不相同，致使不一樣的緣由大可能是和編譯DLL時候指定DLL導出函數的界定符有關係。

VC++支持兩種語言：即C/C++，這也是形成DLL導出函數差別的根源

咱們用VS2008新建個DLL工程，工程名爲"TestDLL"

把默認的源文件後綴 .CPP改成.C（C文件）

輸入測試代碼以下：

01 int _stdcall MyFunction(int iVariant)

02 {

03 return 0;

04 }

爲了導出上面這個函數，咱們有如下幾個方法：

1. 使用傳統的模塊定義文件 (.def)

新建一個 後綴爲.def的文本文件(這裏建一個TestDll.Def)，文件內容爲：

LIBRARY TestDll

EXPORTS

MyFunction

在 Link 時指定輸入依賴文件：/DEF:"TestDll.Def"

2. Visual C++ 提供的方便方法

在01行的int 前加入 __declspec(dllexport) 關鍵字

經過以上兩種方法，咱們就能夠導出MyFunction函數。

咱們用Dependency查看導出的函數：

第一種方法導出的函數爲：

MyFunction

第二種方法導出的函數爲：

_MyFunction@4

__stdcall會使導出函數名字前面加一個下劃線，後面加一個@再加上參數的字節數，好比_MyFunction@4的參數（int iVariant）就是4個字節

__fastcall與 __stdcall相似，不過前面沒有下劃線，而是一個@，好比@MyFunction@4

__cdecl則是始函數名。

小結：若是要導出C文件中的函數，而且不讓編譯器改動函數名，用def文件導出函數。

下面咱們來看一下C++文件

咱們用VS2008新建個DLL工程，工程名爲"TestDLL"

默認的源文件後綴爲 .CPP （即C++文件）。

輸入測試代碼以下：

01 int _stdcall MyFunction(int iVariant)

02 {

03 return 0;

04 }

爲了導出上面這個函數，咱們有如下幾個方法：

3. 使用傳統的模塊定義文件 (.def)

新建一個 後綴爲.def的文本文件(這裏建一個TestDll.Def)，文件內容爲：

LIBRARY TestDll

EXPORTS

MyFunction

在 Link 時指定輸入依賴文件：/DEF:"TestDll.Def"

4. Visual C++ 提供的方便方法

在01行的int 前加入 __declspec(dllexport) 關鍵字

經過以上兩種方法，咱們就能夠導出MyFunction函數。

咱們用Dependency查看導出的函數：

第一種方法導出的函數爲：

MyFunction

第二種方法導出的函數爲：

?MyFunction@@YGHH@Z

能夠看到 第二種方法獲得的 導出函數名 並非咱們想要的，若是在exe中用顯示方法（LoadLibrary、GetProcAddress）調用 MyFunction 確定會失敗。

可是用引入庫(*.LIB)的方式調用，則編譯器自動處理轉換函數名，因此老是沒有問題。

解決這個問題的方法是：

用VC 提供的預處理指示符 "#pragma" 來指定連接選項。

以下：

#pragma comment(linker, "/EXPORT:MyFunction=?MyFunction@@YGHH@Z")

這時，就會發現導出的函數名字表中已經有了咱們想要的MyFunction。但咱們發現原來的那個 ?MyFunction@@YGHH@Z 函數還在，這時就能夠把 __declspec() 修飾去掉，只須要 pragma 指令便可。

並且還可使以下形式：

#pragma comment(linker, "/EXPORT:MyFunction=_MyFunction@4,PRIVATE")

PRIVATE 的做用與其在 def 文件中的做用同樣。更多的#pragram請查看MSDN。

小結：若是要導出C++文件中的函數，而且不讓編譯器改動函數名，用def文件導出函數。

同時能夠用#pragma指令（C 中也能夠用）。

總結：

C++編譯器在生成DLL時，會對導出的函數進行名字改編，而且不一樣的編譯器使用的改編規則不同，所以改編後的名字也是不一樣的（通常涉及到C++ 中的重載等）。

若是利用不一樣編譯器分別生成DLL和訪問DLL的exe程序，後者在訪問該DLL的導出函數時就會出現問題。如上例中函數MyFunction在C++編譯器改編後的名字是?MyFunction@@YGHH@Z。咱們但願編譯後的名字不發生改變，這裏有幾種方法。

第一種方法是經過一個稱爲模塊定義文件DEF來解決。

LIBRARY TestDll

EXPORTS

MyFunction

LIBRARY 用來指定動態連接庫內部名稱。該名稱與生成的動態連接庫名必定要匹配，這句代碼不是必須的。

EXPORTS說明了DLL將要導出的函數，以及爲這些導出函數指定的符號名。

第二種是定義導出函數時加上限定符：extern "C"

如：#define DLLEXPORT_API extern "C" _declspec(dllexport)

但extern "C"只解決了C和C++語方之間調用的問題(extern "C" 是告訴編譯器，讓它按C的方式編譯)，它只能用於導出全局函數這種狀況 而不能導出一個類的成員函數。

同時若是導出函數的調用約定發生改變，即便使用extern "C"，編譯後的函數名仍是會發生改變。例如上面咱們加入_stdcall關鍵字說明調用約定（標準調用約定，也就是WINAPI調用約定）。

#define DLLEXPORT_API extern "C" _declspec(dllexport)

01 DLLEXPORT_API int _stdcall MyFunction(int iVariant)

02 {

03 return 0;

04 }

編譯後函數名MyFunction改編成了_MyFunction@4

經過第一種方法模塊定義文件的方式DLL編譯後導出函數名不會發生改變。

DLL(動態庫)導出函數名亂碼含義

C++編譯時函數名修飾約定規則：

   __stdcall調用約定：

   一、以"?"標識函數名的開始，後跟函數名；

 

   二、函數名後面以"@@YG"標識參數表的開始，後跟參數表；

 

   三、參數表以代號表示：

   X--void

   D--char

   E--unsigned char

   F--short

   H--int

   I--unsigned int

   J--long

   K--unsigned long

   M--float

   N--double

   _N--bool

   ....

   PA--表示指針，後面的代號代表指針類型，若是相同類型的指針連續出現，以"0"代替，一個"0"表明一次重複；

   四、參數表的第一項爲該函數的返回值類型，其後依次爲參數的數據類型,指針標識在其所指數據類型前；

 

   五、參數表後以"@Z"標識整個名字的結束，若是該函數無參數，則以"Z"標識結束。

   其格式爲"?functionname@@YG*****@Z"或"?functionname@@YG*XZ"，例如

                       int Test1(char *var1, unsigned long)-----"?Test1@@YGHPADK@Z"                      void Test2()-----"?Test2@@YGXXZ"

 

   __cdecl調用約定：

   規則同上面的_stdcall調用約定，只是參數表的開始標識由上面的"@@YG"變爲"@@YA"。

   __fastcall調用約定：

   規則同上面的_stdcall調用約定，只是參數表的開始標識由上面的"@@YG"變爲"@@YI"。

   若是要用DEF文件輸出一個"C++"類，則把要輸出的數據和成員的修飾名都寫入.def模塊定義文件

   因此...   經過def文件來導出C++類是很麻煩的,而且這個修飾名是不可避免的

 

 

 

http://blog.csdn.net/iw1210/article/details/29615569

http://www.360doc.com/content/12/0914/09/6973384_236025844.shtml

http://blog.163.com/fenglanghai@126/blog/static/3356877920116555810161/

http://blog.csdn.net/srzhz/article/details/7033985

http://blog.163.com/bbluesnow@126/blog/static/277845452012123114924563/

http://blog.sina.com.cn/s/blog_6a2236590100xbgl.html

http://blog.csdn.net/shandiantianying/article/details/11039733

http://blog.csdn.net/xiaolongwang2010/article/details/8496177