为啥 Cdecl 调用在“标准”P/Invoke 约定中经常不匹配？

Posted 2023-02-22

【中文标题】为啥 Cdecl 调用在“标准”P/Invoke 约定中经常不匹配？

【英文标题】：Why are Cdecl calls often mismatched in the "standard" P/Invoke Convention?为什么 Cdecl 调用在“标准”P/Invoke 约定中经常不匹配？

【发布时间】：2013-03-27 13:58:56

【问题描述】：

我正在开发一个相当大的代码库，其中 C++ 功能是从 C# P/Invoked。

我们的代码库中有很多调用，例如...

C++：

extern "C" int __stdcall InvokedFunction(int);

用对应的C#：

[DllImport("CPlusPlus.dll", ExactSpelling = true, SetLastError = true, CallingConvention = CallingConvention.Cdecl)]
    private static extern int InvokedFunction(IntPtr intArg);

我已经搜索了网络（在我能力范围内），以了解为什么存在这种明显的不匹配。例如，为什么 C# 中有 Cdecl，而 C++ 中有 __stdcall？显然，这会导致堆栈被清除两次，但是，在这两种情况下，变量都以相同的相反顺序被推入堆栈，因此我看不到任何错误，尽管返回信息可能会在以下情况下被清除在调试期间尝试跟踪？

来自 MSDN：http://msdn.microsoft.com/en-us/library/2x8kf7zx%28v=vs.100%29.aspx

// explicit DLLImport needed here to use P/Invoke marshalling
[DllImport("msvcrt.dll", EntryPoint = "printf", CallingConvention = CallingConvention::Cdecl,  CharSet = CharSet::Ansi)]

// Implicit DLLImport specifying calling convention
extern "C" int __stdcall MessageBeep(int);

再一次，C++ 代码中有extern "C"，C# 中有CallingConvention.Cdecl。为什么不是CallingConvention.Stdcall？或者，还有，为什么C++中有__stdcall？

提前致谢！

【参考方案1】：

这在 SO 问题中反复出现，我将尝试将其变成（长）参考答案。 32 位代码背负着不兼容的调用约定的悠久历史。关于如何进行函数调用的选择在很久以前是有意义的，但如今在后端大多是一个巨大的痛苦。 64 位代码只有一个调用约定，谁要再添加一个，谁就会被送到南大西洋的小岛上。

除了Wikipedia article 中的内容之外，我将尝试注释它们的历史和相关性。起点是如何进行函数调用的选择是传递参数的顺序、存储参数的位置以及调用后如何清理。

__stdcall 通过在 16 位 Windows 和 OS/2 中使用的旧的 16 位帕斯卡调用约定进入 Windows 编程。它是所有 Windows api 函数以及 COM 使用的约定。由于大多数 pinvoke 旨在进行操作系统调用，因此如果您未在 [DllImport] 属性中明确指定 Stdcall，则它是默认设置。它存在的一个也是唯一的原因是它指定被调用者清理。这会产生更紧凑的代码，这在他们不得不在 640 KB RAM 中压缩 GUI 操作系统的日子里非常重要。它最大的缺点是它危险。调用者假设的函数参数与被调用者实现的参数之间的不匹配会导致堆栈不平衡。这反过来又会导致极难诊断崩溃。

__cdecl 是用 C 语言编写的代码的标准调用约定。它存在的主要原因是它支持使用可变数量的参数进行函数调用。常见于 C 代码中，具有 printf() 和 scanf() 等函数。副作用是由于调用者知道实际传递了多少参数，因此清理的是调用者。在 [DllImport] 声明中忘记 CallingConvention = CallingConvention.Cdecl 是一个非常常见的错误。

__fastcall 是一个定义不明确的调用约定，具有相互不兼容的选择。这在 Borland 编译器中很常见，这家公司曾经在编译器技术方面非常有影响力，直到它们解体。也是许多微软员工的前雇主，包括 C# 名声的 Anders Hejlsberg。发明它是为了通过 CPU 寄存器而不是堆栈传递 一些 参数来降低参数传递的成本。由于标准化较差，托管代码不支持它。

__thiscall 是为 C++ 代码发明的调用约定。与 __cdecl 非常相似，但它还指定了如何将隐藏的类对象的 this 指针传递给类的实例方法。 C++ 中超越 C 的额外细节。虽然它看起来很容易实现，但 .NET pinvoke marshaller 不支持它。您无法调用 C++ 代码的主要原因。复杂的不是调用约定，而是 this 指针的正确值。由于 C++ 对多重继承的支持，这可能会变得非常复杂。只有 C++ 编译器才能弄清楚到底需要传递什么。而且只有完全相同的 C++ 编译器为 C++ 类生成代码，不同的编译器在如何实现 MI 以及如何优化 MI 方面做出了不同的选择。

__clrcall 是托管代码的调用约定。它是其他的混合，this 指针传递如 __thiscall，优化参数传递如 __fastcall，参数顺序如 __cdecl 和调用者清理如 __stdcall。托管代码的最大优势是内置在抖动中的验证器。这确保调用者和被调用者之间永远不会不兼容。从而使设计人员能够利用所有这些约定的优势，但没有麻烦的包袱。一个示例，说明托管代码如何在保证代码安全的开销的情况下保持与本机代码的竞争力。

您提到extern "C"，了解其重要性对于互操作性也很重要。语言编译器经常装饰导出函数的名称带有额外的字符。也称为“名称修改”。这是一个非常糟糕的技巧，永远不会停止制造麻烦。您需要了解它以确定 [DllImport] 属性的 CharSet、EntryPoint 和 ExactSpelling 属性的正确值。有很多约定：

Windows api 装饰。 Windows 最初是一个非 Unicode 操作系统，对字符串使用 8 位编码。 Windows NT 是第一个以 Unicode 为核心的系统。这导致了一个相当大的兼容性问题，旧代码将无法在新操作系统上运行，因为它将 8 位编码的字符串传递给需要 utf-16 编码的 Unicode 字符串的 winapi 函数。他们通过编写每个 winapi 函数的 两个 版本来解决这个问题。一种采用 8 位字符串，另一种采用 Unicode 字符串。并通过在旧版本（A = Ansi）的名称末尾粘贴字母 A 和在新版本（W = 宽）的末尾粘贴 W 来区分两者。如果函数不接受字符串，则不添加任何内容。 pinvoke marshaller 无需您的帮助即可自动处理此问题，它只会尝试查找所有 3 个可能的版本。但是，您应该始终指定 CharSet.Auto（或 Unicode），将字符串从 Ansi 转换为 Unicode 的传统函数的开销是不必要且有损的。

__stdcall 函数的标准修饰是 _foo@4。前导下划线和一个 @n 后缀，表示参数的组合大小。如果调用者和被调用者不同意参数的数量，则此后缀旨在帮助解决令人讨厌的堆栈不平衡问题。效果很好，虽然错误消息不是很好，但 pinvoke 编组器会告诉您它找不到入口点。值得注意的是，Windows 在使用 __stdcall 时，不 使用这种装饰。这是故意的，让程序员有机会获得正确的 GetProcAddress() 参数。 pinvoke marshaller 也会自动处理这个问题，首先尝试找到带有 @n 后缀的入口点，然后尝试不带后缀的入口点。

__cdecl 函数的标准修饰是 _foo。一个前导下划线。 pinvoke marshaller 会自动对此进行排序。可悲的是，__stdcall 的可选@n 后缀不允许它告诉您您的 CallingConvention 属性错误，损失巨大。

C++ 编译器使用名称修饰，产生真正奇怪的名称，例如“??2@YAPAXI@Z”，“operator new”的导出名称。这是一个必要的邪恶，因为它支持函数重载。它最初被设计为使用遗留 C 语言工具来构建程序的预处理器。这使得有必要通过给它们不同的名称来区分void foo(char) 和void foo(int) 重载。这就是extern "C" 语法发挥作用的地方，它告诉 C++ 编译器不将名称修饰应用于函数名称。大多数编写互操作代码的程序员有意使用它来使其他语言的声明更易于编写。这实际上是一个错误，装饰对于捕捉不匹配非常有用。您将使用链接器的 .map 文件或 Dumpbin.exe /exports 实用程序来查看修饰名称。 undname.exe SDK 实用程序可以非常方便地将损坏的名称转换回其原始 C++ 声明。

所以这应该清除属性。您使用 EntryPoint 给出导出函数的确切名称，该名称可能与您想在自己的代码中调用它的名称不匹配，尤其是对于 C++ 错位名称。并且您使用 ExactSpelling 告诉 pinvoke marshaller 不要尝试查找替代名称，因为您已经给出了正确的名称。

我会暂时缓解我的写作痉挛。您的问题标题的答案应该很清楚，Stdcall 是默认设置，但与用 C 或 C++ 编写的代码不匹配。而且您的 [DllImport] 声明不兼容。这应该会在来自 PInvokeStackImbalance 托管调试器助手的调试器中产生警告，这是一个旨在检测错误声明的调试器扩展。并且可以相当随机地使您的代码崩溃，尤其是在发布版本中。确保您没有关闭 MDA。

【讨论】：

感谢您的课程。我对 P/Invoke 有了新的尊重。而且我更感谢 __clrcall 和 C# 中缺乏多重继承。

+1 我有几个轻度悬垂的 cmets。您谈论的是__fastcall，但这实际上是一个 MS 调用约定。通常，它可以被视为 fastcall 约定系列的一部分。 MS fastcall、Borland fastcall 等。MS 版本__fastcall 仅使用两个 x86 寄存器：ECX、EDX。 Borland 版本，今天在 Delphi 世界中作为register 约定存在，使用三个寄存器。 EAX 被添加到组合中。

我的其他评论与名称装饰有关。我最近在这里回答一个问题时发现，不同的编译器对__stdcall 有不同的修饰。似乎 MS、Borland 和 GNU 工具集都不同。我怀疑其他编译器会引入更多变体。

汉斯，谢谢你的解释！我只能通过筛选无数点来收集点点滴滴。将所有这些信息集中在一个地方真是太好了！另外，谢谢你们，也感谢你们！这对我来说仍然很重要，但这非常有帮助，特别是关于为什么事情处于这种混乱/混合示例状态的历史！

这很棒。我以前从未在同一个地方看到所有这些信息。我希望我能给这个答案多个赞成票。

【参考方案2】：

cdecl 和 stdcall 在 C++ 和 .NET 之间都是有效且可用的，但它们应该在两个非托管和托管世界之间保持一致。因此，您对 InvokedFunction 的 C# 声明无效。应该是标准调用。 MSDN 示例只提供了两个不同的示例，一个使用 stdcall (MessageBeep)，一个使用 cdecl (printf)。它们是无关的。

【讨论】：

同意；建议对“调用约定”进行一些研究，以了解差异为何如此重要。