• _cdecl 与 _stdcall 区别


    前段时间编程时遇到过这么一个问题,我写了一个DLL,把里面的一个函数导出来,然后再定义一个签名与其匹配的函数指针,动态地把这个DLL加载起来(LoadLibrary),得到函数指针后,一调用,结果报错了,错误如下:

    Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

        我不知道是什么原因就在网上查了下,得到如下结论:

    你定义函数指针原型时出错。

    其实你定义的没有错,但是编译器不认识而已,因为你调用的dll函数是一个远函数,而且是一个C函数,你得告诉编译器它是个c函数才行。那么你就可以在定义该函数的时候加上一句话,

    FAR PASCAL 或者 __stdcall 这个就OK了。

    具体做法:

    比如说你要定义一个 返回类型为空,参数为空的函数指针:

    typedef void (*LPFUN)(void);

    这样确实跟我们dll里的函数匹配了,上面也说了,我们应该添上几个字,告诉编译器这个是一个远的C函数。

    typedef void (WINAPI *LPFUN)(void);

    typedef void (__stdcall *LPFUN)(void);

    typedef void    (FAR PASCAL *LPFUN)    (void);

    像上面这样定义就OK了,如果用的是VC++,那么直接用第一种定义就ok了。

    注意,上面是使用 MFC (DLL)的做法。

    如果是WIN32 DLL,得相应的去掉WINAPI ,__stdcall ,FAR PASCAL 这几个参数。因为WIN32 DLL 默认的入栈方式为 __cedcall方式,不是__stdcall方式。

    具体的组合方式太多了,反正知道错误的原因是声明相应的函数未匹配就行了。实在不行,一个一个的试吧

    函数定义的调用规则,和实际的调用规则不同。如 __stdcall 类型的函数却用 __cdecl 的调用规则。极可能是其中一个函数指针有问题。

    编译器默认的是__cdecl,而函数指针是由void*传进去的__stdcall方式,由于编译时不会报错,结果出现了运行时异常。

     

        最后问题解决了,但我对__cdecl和__stdcall还是不太理解,就在网上找了一些资料,终于把这些弄明白了,所以就写个篇博客对这个知识点进行一番小的总结。我觉得比较重要的或者是需要注意的都用红色标识出来了。

    ----------------------------------------------------------------------------------------------

        _cdecl是C和C++程序的缺省调用方式。每一个调用它的函数都包含清空堆栈的代码,
    所以产生的可执行文件大小会比调用_stdcall函数的大。函数采用从右到左的压栈方式
    。VC将函数编译后会在函数名前面加上下划线前缀。
        _stdcall是Pascal程序的缺省调用方式,通常用于Win32 Api中,函数采用从右到左的压
    栈方式,自己在退出时清空堆栈。VC将函数编译后会在函数名前面加上下划线前缀,在函数名后加上"@"和参数的字节数。
        _fastcall方式的函数采用寄存器传递参数,VC将函数编译后会在函数名前面加上"@"前
    缀,在函数名后加上"@"和参数的字节数。


        这两个关键字看起来似乎很少和我们打交道,但是看了下面的定义(来自windef.h),你一定会觉得惊讶:
          #define CALLBACK      __stdcall
          #define WINAPI     __stdcall
          #define WINAPIV       __cdecl
          #define APIENTRY      WINAPI
          #define APIPRIVATE    __stdcall
          #define PASCAL     __stdcall
          #define cdecl _cdecl
          #ifndef CDECL
          #define CDECL _cdecl
          #endif
        几乎我们写的每一个WINDOWS API函数都是__stdcall类型的,为什么??
        首先,我们谈一下两者之间的区别:
        WINDOWS的函数调用时需要用到栈(STACK,一种先入后出的存储结构)。当函数调用完成后,栈需要清除,这里就是问题的关键,如何清除??
        如果我们的函数使用了_cdecl,那么栈的清除工作是由调用者,用COM的术语来讲就是客户来完成的。这样带来了一个棘手的问题,不同的编译器产生栈的方式不尽相同,那么调用者能否正常的完成清除工作呢?答案是不能。
        如果使用__stdcall,上面的问题就解决了,函数自己解决清除工作。所以,在跨(开发)平台的调用中,我们都使用__stdcall(虽然有时是以WINAPI的样子出现)。那么为什么还需要_cdecl呢?当我们遇到这样的函数如fprintf()它的参数是可变的,不定长的,被调用者事先无法知道参数的长度,事后的清除工作也无法正常的进行,因此,这种情况我们只能使用_cdecl。到这里我们有一个结论,如果你的程序中没有涉及可变参数,最好使用__stdcal
    l关键字

       _stdcall

        在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 + 12处保存了b

    mov esp,ebp 恢复esp

    pop ebp

    ret 8

        而在编译时,这个函数的名字被翻译成_function@8

    注意不同编译器会插入自己的汇编代码以提供编译的通用性,但是大体代码如此。其中在函数开始处保留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 function

    add 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)

    thiscall

    thiscall是唯一一个不能明确指明的函数修饰,因为thiscall不是关键字。它是C++类成员函数缺省的调用约定。由于成员函数调用还有一个this指针,因此必须特殊处理,thiscall意味着:

    参数从右向左入栈

    如果参数个数确定,this指针通过ecx传递给被调用者;如果参数个数不确定,this指针

    在所有参数压栈后被压入堆栈。

    对参数个数不定的,调用者清理堆栈,否则函数自己清理堆栈

    为了说明这个调用约定,定义如下类和使用代码:

    class A

    {

    public:

    int function1(int a,int b);

    int function2(int a,...);

    };

    int A::function1 (int a,int b)

    {

    return a+b;

    }

    #i nclude

    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);

    }

    callee函数被翻译成汇编后就变成:

    //函数function1调用

    0401C1D push 2

    00401C1F push 1

    00401C21 lea ecx,[ebp-8]

    00401C24 call function1 注意,这里this没有被入栈

    //函数function2调用

    00401C29 push 3

    00401C2B push 2

    00401C2D push 1

    00401C2F push 3

    00401C31 lea eax,[ebp-8] 这里引入this指针

    00401C34 push eax

    00401C35 call function2

    00401C3A add esp,14h

    可见,对于参数个数固定情况下,它类似于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,[ebp+8]

    add eax,[ebp+12]

    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函数将告诉你,堆栈被破坏了。

  • 相关阅读:
    .Net连接字符串设置连接池大小显著提高数据库速度
    转载:MongoDB之旅(超赞,适合初学者)
    MongoDB安装成为Windows服务及日常使用遇到问题总结
    开启Windows文件共享必须开启的两个服务
    Cocos2d-JS中瓦片地图API
    EF-CodeFirst 继承关系TPH、TPT、TPC
    MVC5-4 ViewResult
    MVC5-3 Result分析
    MVC5-2 MVC的管道流与路由
    MVC5-1 ASP.NET的管道流
  • 原文地址:https://www.cnblogs.com/oneway1990/p/9007247.html
Copyright © 2020-2023  润新知