在 Visual Studio 中使用自定义 prolog 和 epilog 代码编写裸函数
-
23-08-2019 - |
题
我正在 dll 中编写一些插件代码,该代码由我无法控制的主机调用。
主机假设插件导出为 __stdcall 函数。主机被告知函数的名称和它期望的参数的详细信息,并通过 LoadLibrary、GetProcAddress 动态地调用它,并手动将参数推入堆栈。
通常插件 dll 会公开一个常量接口。我的插件公开了一个在 dll 加载时配置的接口。为了实现这一点,我的插件公开了一组在编译 dll 时定义的标准入口点,并根据需要将它们分配给正在公开的内部功能。
每个内部函数可能采用不同的参数,但这会与物理入口点名称一起传达给主机。我的所有物理 dll 入口点都被定义为采用单个 void * 指针,并且我自己通过从第一个参数的偏移量和已传送到主机的已知参数列表来从堆栈中编组后续参数。
主机可以使用正确的参数成功调用我的插件中的函数,并且一切正常......但是,我知道a)我的函数没有像预期的那样清理堆栈,因为它们被定义为采用 4 字节指针的 __stdcall 函数,因此它们总是在即使调用者已将更多参数压入堆栈,也会结束。b) 我无法处理不带参数的函数,因为 ret 4 会在我返回时从堆栈中弹出过多的 4 个字节。
从我的插件追踪到主机的调用代码后,我可以看到实际上 a) 没什么大不了的;主机会丢失一些堆栈空间,直到它从调度调用返回,此时它会清理其堆栈帧,从而清理我的垃圾;然而...
我可以通过切换到 __cdecl 并且根本不清理来解决 b) 问题。我认为我可以通过切换到裸函数并编写我自己的通用参数清理代码来解决a)问题。
因为我知道刚刚调用的函数使用的参数空间量,所以我希望它会像下面这样简单:
extern "C" __declspec(naked) __declspec(dllexport) void * __stdcall EntryPoint(void *pArg1)
{
size_t argumentSpaceUsed;
{
void *pX = RealEntryPoint(
reinterpret_cast<ULONG_PTR>(&pArg1),
argumentSpaceUsed);
__asm
{
mov eax, dword ptr pX
}
}
__asm
{
ret argumentSpaceUsed
}
}
但这不起作用,因为 ret 需要编译时间常量......有什么建议么?
更新:
感谢罗布·肯尼迪的建议,我得到了这个,这似乎有效......
extern "C" __declspec(naked) __declspec(dllexport) void * __stdcall EntryPoint(void *pArg1)
{
__asm {
push ebp // Set up our stack frame
mov ebp, esp
mov eax, 0x0 // Space for called func to return arg space used, init to 0
push eax // Set up stack for call to real Entry point
push esp
lea eax, pArg1
push eax
call RealEntryPoint // result is left in eax, we leave it there for our caller....
pop ecx
mov esp,ebp // remove our stack frame
pop ebp
pop edx // return address off
add esp, ecx // remove 'x' bytes of caller args
push edx // return address back on
ret
}
}
这看起来合适吗?
解决方案
自从 ret
需要一个常量参数,您需要安排您的函数具有常量数量的参数,但这种情况仅在您准备从函数返回时才需要。因此,在函数结束之前,执行以下操作:
- 将返回地址从堆栈顶部弹出并将其存储在临时存储器中;
ECX
是个好地方。 - 从堆栈中删除可变数量的参数,可以通过单独弹出每个参数,也可以通过调整
ESP
直接地。 - 将返回地址推回到堆栈中。
- 使用
ret
不断的争论。
顺便说一下,在一般情况下,您提到的(a)问题确实是一个问题。您很幸运,调用者似乎总是使用帧指针而不是堆栈指针来引用其自己的局部变量。不过,不需要函数来执行此操作,并且不能保证主机程序的未来版本将继续以这种方式工作。编译器还负责仅在调用期间将一些寄存器值保存在堆栈上,然后期望能够在之后再次将它们弹出。你的代码会打破这一点。