南京建设工程公共资源交易中心网站,百度教育智能小程序,广东网站建设排名,西安个人做企业网站函数名字修饰#xff08;Decorated Name#xff09;方式 函数的名字修饰#xff08;Decorated Name#xff09;就是编译器在编译期间创建的一个字符串#xff0c;用来指明函数的定义或原型。 正在装载数据…… LINK程序或其他工具有时需要指定函数的名字修饰来定位函数的… 函数名字修饰Decorated Name方式 函数的名字修饰Decorated Name就是编译器在编译期间创建的一个字符串用来指明函数的定义或原型。 正在装载数据…… LINK程序或其他工具有时需要指定函数的名字修饰来定位函数的正确位置。多数情况下程序员并不需要知道函数的名字修饰LINK程序或其他工具会自动区分他们。当然在某些情况下需要指定函数的名字修饰例如在C程序中为了让LINK程序或其他工具能够匹配到正确的函数名字就必须为重载函数和一些特殊的函数如构造函数和析构函数指定名字装饰。另一种需要指定函数的名字修饰的情况是在汇编程序中调用C或C的函数。如果函数名字调用约定返回值类型或函数参数有任何改变原来的名字修饰就不再有效必须指定新的名字修饰。C和C程序的函数在内部使用不同的名字修饰方式下面将分别介绍这两种方式。 1. C编译器的函数名修饰规则 对于__stdcall调用约定编译器和链接器会在输出函数名前加上一个下划线前缀函数名后面加上一个“”符号和其参数的字节数例如_functionnamenumber。__cdecl调用约定仅在输出函数名前加上一个下划线前缀例如_functionname。__fastcall调用约定在输出函数名前加上一个“”符号后面也是一个“”符号和其参数的字节数例如functionnamenumber 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 longDWORD M--float N--double _N--bool U--struct .... 指针的方式有些特别用PA表示指针用PB表示const类型的指针。后面的代号表明指针类型如果相同类型的指针连续出现以“0”代替一个“0”代表一次重复。U表示结构类型通常后跟结构体的类型名用“”表示结构类型名的结束。函数的返回值不作特殊处理它的描述方式和函数参数一样紧跟着参数表的开始标志也就是说函数参数表的第一项实际上是表示函数的返回值类型。参数表后以“Z”标识整个名字的结束如果该函数无参数则以“Z”标识结束。下面举两个例子假如有以下函数声明 int Function1 (char *var1,unsigned long); 其函数修饰名为“?Function1YGHPADKZ”而对于函数声明 void Function2(); 其函数修饰名则为“?Function2YGXXZ” 。 对于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其函数修饰名为“?FunctionCTestAAEXHZ”字符串“AAE”表示这是一个私有函数。成员函数CopyInfo只有一个参数是对类CTest的const引用参数其函数修饰名为“?CopyInfoCTestIAEXABV1Z”。DrawText是一个比较复杂的函数声明不仅有字符串参数还有结构体参数和HDC句柄参数需要指出的是HDC实际上是一个HDC__结构类型的指针这个参数的表示就是“PAUHDC__”其完整的函数修饰名为“?DrawTextCTestQAEJPAUHDC__JPBDUtagRGBQUADE_NZ”。InsightClass是一个共有的const函数它的成员函数标识是“QBE”完整的修饰名就是“?InsightClassCTestQBEJKZ”。 无论是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中的MakeFunb和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函数的名字修饰就是“_MakeFun4”。b包含了a提供的头文件中MakeFun函数声明但是由于b采用的是C语言编译所以MakeFun在b模块中被按照C的名字修饰规则命名为“?MakeFunYGJJZ”编译过程相安无事链接程序时c的链接器就到a.lib中去找“?MakeFunYGJJZ”但是a.lib中只有“_MakeFun4”没有“?MakeFunYGJJZ”于是链接器就报告 error LNK2001: unresolved external symbol ?MakeFunYGJJZ 解决的方法和简单就是要让b模块知道这个函数是C语言编译的extern C可以做到这一点。一个采用C语言编译的库应该考虑到使用这个库的程序可能是C程序使用C编译器所以在设计头文件时应该注意这一点。通常应该这样声明头文件 #ifdef _cplusplus extern C { #endif long MakeFun(long lFun); #ifdef _cplusplus } #endif 这样C的编译器就知道MakeFun的修饰名是“_MakeFun4”就不会有链接错误了。 许多人不明白为什么我使用的编译器都是VC的编译器还会产生“error LNK2001”错误其实VC的编译器会根据源文件的扩展名选择编译方式如果文件的扩展名是“.C”编译器会采用C的语法编译如果扩展名是“.cpp”编译器会使用C的语法编译程序所以最好的方法就是使用extern C。 1. 以“?”标识函数名的开始后跟函数名 函数名后面以“YG”标识参数表的开始后跟参数表 2. 参数表以代号表示 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”代表一次重复 3. 参数表的第一项为该函数的返回值类型其后依次为参数的数据类型指针标识在其所指数据类型前 4. 参数表后以“Z”标识整个名字的结束如果该函数无参数则以“Z”标识结束。 其格式为“?functionnameYG*****Z”或“?functionnameYG*XZ”例如 int Test1char *var1unsigned long-----“?Test1YGHPADKZ” void Test2 -----“?Test2YGXXZ” 2 __cdecl调用约定 规则同上面的 _stdcall 调用约定只是参数表的开始标识由上面的“YG”变为“YA”。 2__fastcall调用约定 规则同上面的_stdcall调用约定只是参数表的开始标识由上面的“YG”变为“YI”。 VC对函数的省缺声明是__cedcl将只能被C/C调用。 CB在输出函数声明时使用4种修饰符号 : __cdecl cb 的默认值它会在输出函数名前加 _并保留此函数名不变参数按照从右到左的顺序依次传递给栈也可以写成_cdecl和cdecl形式。 __fastcall 修饰的函数的参数将尽可能的使用寄存器来处理其函数名前加参数按照从左到右的顺序压栈 __pascal 它说明的函数名使用 Pascal 格式的命名约定。这时函数名全部大写。参数按照从左到右的顺序压栈 __stdcall 使用标准约定的函数名。函数名不会改变。使用 __stdcall 修饰时。参数按照由右到左的顺序压栈也可以是_stdcall C语言函数调用约定 在C语言中假设我们有这样的一个函数 int function(int a,int b) 调用时只要用 result function(1,2) 这样的方式就可以使用这个函数。但是当高级语言被编译成计算机可以识别的机器码时有一个问题就出现来在CPU中计算机没有办法知道一个函数调用需要多少个、什么样的参数也没有硬件可以保存这些参数。也就是说计算机不知道怎么给这个函数传递参数传递参数的工作必须由函数调用者和函数本身来协调。为此计算机提供了一种被称为栈的数据结构来支持参数传递。 栈是一种先后进先出的数据结构栈有一个存储区、一个栈顶指针。栈顶指针指向堆栈中第一个可用的数据项被称为栈顶。用户可以在栈顶上方向栈中加入数据这个操作被称为压栈 (Push)压栈以后栈顶自动变成新加入数据项的位置栈顶指针也随之修改。用户也可以从堆栈中取走栈顶称为弹出栈 (pop)弹出栈后栈顶下的一个元素变成栈顶栈顶指针随之修改。 函数调用时调用者依次把参数压栈然后调用函数函数被调用以后在堆栈中取得数据并进行计算。函数计算结束以后或者调用者、或者函数本身修改堆栈使堆栈恢复原装。 在参数传递中有两个很重要的问题必须得到明确说明 当参数个数多于一个时按照什么顺序把参数压入堆栈 函数调用后由谁来把堆栈恢复原状 在高级语言中通过函数调用约定来说明这两个问题。常见的调用约定有 stdcall cdecl fastcall thiscall naked call stdcall调用约定 stdcall很多时候被称为pascal调用约定因为pascal是早期很常见的一种教学用计算机程序设计语言其语法严谨使用的函数调用约定就是stdcall。在Microsoft C系列的C/C编译器中常常用PASCAL宏来声明这个调用约定类似的宏还有WINAPI和CALLBACK。 stdcall调用约定声明的语法为(以前文的那个函数为例 int __stdcall function(int a,int b) stdcall的调用约定意味着1参数从右向左压入堆栈2函数自身修改堆栈 3)函数名自动加前导的下划线后面紧跟一个符号其后紧跟着参数的尺寸 以上述这个函数为例参数b首先被压栈然后是参数a函数调用function(1,2)调用处翻译成汇编语言将变成 push 2 // 第二个参数入栈 push 1 // 第一个参数入栈 call function // 调用参数注意此时自动把cs:eip入栈 而对于函数自身则可以翻译为 push ebp // 保存ebp寄存器该寄存器将用来保存堆栈的栈顶指针可以在函数退出时恢复 mov ebp,esp // 保存堆栈指针 mov eax,[ebp 8H] // 堆栈中ebp指向位置之前依次保存有 ebp,cs:eip,a,b,ebp 8指向 a add eax,[ebp 0CH] // 堆栈中ebp 1 2处保存了b mov esp,ebp // 恢复esp pop ebp ret 8 而在编译时这个函数的名字被翻译成_function8 注意不同编译器会插入自己的汇编代码以提供编译的通用性但是大体代码如此。 其中在函数开始处保留esp到ebp中在函数结束恢复是编译器常用的方法。 从函数调用看2和1依次被push进堆栈而在函数中又通过相对于ebp(即刚进函数时的堆栈指针的偏移量存取参数。 函数结束后ret 8 表示清理8个字节的堆栈函数自己恢复了堆栈。 cdecl调用约定 cdecl 调用约定又称为C调用约定是C语言缺省的调用约定它的定义语法是 int function (int a ,int b) //不加修饰就是C调用约定 int __cdecl function(int a,int b) //明确指出C调用约定 cdecl调用约定的参数压栈顺序是和 stdcall是一样的参数首先由有向左压入堆栈。 所不同的是函数本身不清理堆栈调用者负责清理堆栈。 由于这种变化C 调用约定允许函数的参数的个数是不固定的这也是C语言的一大特色。 对于前面的function函数使用cdecl后的汇编码变成 调用处 push 1 push 2 call functionadd esp,8 // 注意这里调用者在恢复堆栈 被调用函数_function处 push ebp // 保存ebp寄存器该寄存器将用来保存堆栈的栈顶指针可以在函数退出时恢复 mov ebp,esp // 保存堆栈指针 mov eax,[ebp 8H] // 堆栈中ebp指向位置之前依次保存有 ebp, cs:eip,a,b,ebp 8指向a add eax,[ebp 0CH] // 堆栈中ebp 12处保存了b mov esp,ebp // 恢复esp pop ebp ret // 注意这里没有修改堆栈 MSDN中说该修饰自动在函数名前加前导的下划线因此函数名在符号表中被记录为_function但是我在编译时似乎没有看到这种变化。 由于参数按照从右向左顺序压栈因此最开始的参数在最接近栈顶的位置因此当采用不定个数参数时第一个参数在栈中的位置肯定能知道只要不定的参数个数能够根据第一个后者后续的明确的参数确定下来就可以使用不定参数例如对于CRT中的sprintf函数定义为 int sprintf(char* buffer,const char* format,...) 由于所有的不定参数都可以通过 format 确定因此使用不定个数的参数是没有问题的。 fastcall调用约定 fastcall调用约定和stdcall类似它意味着 函数的第一个和第二个DWORD参数或者尺寸更小的通过ecx和edx传递其他参数通过从右向左的顺序压栈 被调用函数清理堆栈 函数名修改规则同stdcall 其声明语法为int fastcall function(int a,int b) 为了说明这个调用约定定义如下类和使用代码 class A { public: int function1(int a,int b); int function2(int a,...); }; int A::function1 (int a,int b) { return ab; } int A::function2(int a,...) { va_list ap; va_start(ap,a); int i; int result 0; for(i 0 ; i a ; i ) { result va_arg(ap,int); } return result; } void callee() { A a; a.function1 (1,2); a.function2(3,1,2,3); } // 下面这段汇编代码是原文章的我觉得有问题还是自己反汇编看看 //函数function1调用0401C1D push 200401C1F push 100401C21 lea ecx,[ebp-8]00401C24 call function1 // 注意这里this没有被入栈 //函数function2调用00401C29 push 300401C2B push 200401C2D push 100401C2F push 300401C31 lea eax,[ebp-8] 这里引入this指针00401C34 push eax00401C35 call function200401C3A add esp,14h 以下代码是我亲自动手分析的 上面的C代码必须包含 stdarg.h 提供动态参数头文件 int A::function1 (int a,int b) // { 004113A0 push ebp 004113A1 mov ebp,esp 004113A3 sub esp,0CCh 004113A9 push ebx 004113AA push esi 004113AB push edi 004113AC push ecx 004113AD lea edi,[ebp-0CCh] 004113B3 mov ecx,33h 004113B8 mov eax,0CCCCCCCCh 004113BD rep stos dword ptr es:[edi] 004113BF pop ecx 004113C0 mov dword ptr [ebp-8],ecx return ab; 004113C3 mov eax,dword ptr [a] 004113C6 add eax,dword ptr [b] } 004113C9 pop edi 004113CA pop esi 004113CB pop ebx 004113CC mov esp,ebp 004113CE pop ebp 004113CF ret 8 void callee() { 00411460 push ebp 00411461 mov ebp,esp 00411463 sub esp,0CCh 00411469 push ebx 0041146A push esi 0041146B push edi 0041146C lea edi,[ebp-0CCh] 00411472 mov ecx,33h 00411477 mov eax,0CCCCCCCCh 0041147C rep stos dword ptr es:[edi] A a; a.function1 (1,2); 0041147E push 2 // 参数 2 入栈 00411480 push 1 // 参数 1 入栈 00411482 lea ecx,[a] // this 指针 ---- ECX 00411485 call A::function1 (411050h) a.function2(3,1,2,3); 0041148A push 3 0041148C push 2 0041148E push 1 00411490 push 3 00411492 lea eax,[a] // 这里 this 指针入栈了对照 callee 对 function1 的调用 00411495 push eax // 对 this 的处理是不同的 00411496 call A::function2 (411122h) // 此处调用者自己没有恢复堆栈 // 由于上面的入栈顺序可知在 function 2中 当保存ebp 后(打开stack frame后)堆栈的状态如下. ebp // 保存的 EBP 的值, 且 此时ebp指向该处 RetAddr // 返回地址 this指针 // 入栈的 this 指针 参数 3 // 下面是入栈的参数, 从右向左入栈 参数 1 参数 2 参数 3 0041149B add esp,14h // 此处调用者自己恢复堆栈 //.............下面的汇编代码是 检查堆栈和恢复 callee 堆栈的操作不再写了 } 可见对于参数个数固定情况下它类似于stdcall不定时则类似cdecl naked call 调用约定 这是一个很少见的调用约定一般程序设计者建议不要使用。编译器不会给这种函数增加初始化和清理代码更特殊的是你不能用return返 回返回值只能用插入汇编返回结果。这一般用于实模式驱动程序设计假设定义一个求和的加法程序可以定义为 __declspec(naked) int add(int a,int b) { __asm mov eax,a __asm add eax,b __asm ret } 注意这个函数没有显式的return返回值返回通过修改eax寄存器实现而且连退出函数的ret指令都必须显式插入。 上面代码被翻译成汇编以后变成 mov eax,[ebp8] add eax,[ebp12] ret 8 注意这个修饰是和__stdcall及cdecl结合使用的前面是它和cdecl结合使用的代码对于和stdcall结合的代码则变成 __declspec(naked) int __stdcall function(int a,int b) { __asm mov eax,a __asm add eax,b __asm ret 8 //注意后面的8 } 至于这种函数被调用则和普通的cdecl及stdcall调用函数一致。 函数调用约定导致的常见问题 如果定义的约定和使用的约定不一致则将导致堆栈被破坏导致严重问题下面是两种常见的问题 函数原型声明和函数体定义不一致 DLL导入函数时声明了不同的函数约定 以后者为例假设我们在dll种声明了一种函数为 __declspec(dllexport) int func(int a,int b);//注意这里没有stdcall使用的是cdecl 使用时代码为 typedef int (*WINAPI DLLFUNC)func(int a,int b); hLib LoadLibrary(...); DLLFUNC func (DLLFUNC)GetProcAddress(...) //这里修改了调用约定 result func(1,2); //导致错误 由于调用者没有理解WINAPI的含义错误的增加了这个修饰上述代码必然导致堆栈被破坏 MFC在编译时插入的checkesp函数将告诉你堆栈被破坏了。
