x86 Windows 上使用 STDCALL ABI 的闭包会导致 LibFFI 3.2.1 出现堆栈溢出异常

Question

我正在使用libffi library (version 3.2.1)通过允许脚本编写者创建用于调用 API 函数或定义与 API 兼容的回调函数的原型(prototype)，启用脚本语言的 API 接口(interface)。

在 x64 上，Windows 上仅使用一种调用约定； libffi 中的 WIN64。这与库中的闭包配合得很好，脚本编写者可以轻松创建可在 EnumChildWindows(HWND, WNDENUMPROC, LPARAM) 等调用中使用的回调函数

但是，在 x86 上，使用 LibFFI 使用 STDCALL ABI 创建的闭包调用 EnumChildWindows 会导致发生堆栈溢出异常。根据报告的问题，这是由于在调用 Trampoline 函数时错误分配了参数。 ( x86 stdcall (win32) incorrectly aligns stack arguments ， win32 x86 stdcall closure: incorrectly restored stack after closure call )。

我已尝试应用这些问题报告中提到的补丁，但是它们似乎无法解决我的测试用例的问题。我有另一个测试用例，通过创建一个不带任何参数的回调函数来确定它是否真正是参数对齐；从外部二进制文件调用它。此 STDCALL 函数被正确调用，并且不会出现任何问题，因为不需要参数对齐。

在绝望的状态下，我尝试使用与 3.2.1 相同的工具链编译 libffi 存储库的提示版本，但是该版本提示不支持 x86 windows 目标(sysv.S 中的 asm 语法错误)。由于 CRT 静态链接到生成的静态库，我需要在 MSVC 中编译该库。

最后，我的解决方案问题包含几个选项

• 是否有人有 3.2.1 的补丁来修复 Windows x86 上的 stdcall 问题
• 有谁知道如何使用 MSVC 为 x86 目标编译提示版本
• 谁能告诉我如何将 LibFFI 编译为具有完全静态链接依赖项的静态库(CRT/pthreads，我尝试使用 gcc -static ... -static-libgcc -lpthreads -lrt)，因为我的尝试仍然会产生'关于 pthread 的未解析符号

我已经寻找解决方案一个多星期了，我假设我遗漏了一些明显的东西，因为该库在许多项目中使用。

谢谢，
巴斯

Answer 1

在进一步的研究中，我发现Java Native Access中使用了libffi的一个分支。 。此版本的 LibFFI 包含我正在寻找的修复程序，并且 x86 stdcall 闭包已成功执行。此版本的 LibFFI 可以使用 MSVCC 成功编译。

这算作我原来问题的可能选项列表中的第一个解决方案。