在 Windows x86-64 下异常时将多少推入 32 位堆栈? [英] How much is pushed onto a 32-bit stack under Windows x86-64 on an exception?

问题描述

在这个这个问题中，我提供了一些关于我已经实现的并行语言的背景.编译器生成原生 x86-32 代码.

In this this question, I give some background on a parallel language I have implemented. The compiler generates native x86-32 code.

一个关键的实现决策是从堆中为每个函数(调用)分配堆栈空间.这允许递归，直到你用完 VM，并为词法范围启用仙人掌堆栈，甚至为嵌套的并行子等.

A key implementation decision is to allocate stack space from the heap for every function (call). This allows for recursion until you run out of VM, and enables a cactus stack for lexical scopes even for nested parallel children, etc.

编译器的代码生成器可以计算函数本身需要多少堆栈空间；这很混乱但很简单，而且它已经做得很好了.操作系统调用的堆栈需求没有问题；我的函数没有任何作用(如果需要，代码切换到标准的大堆栈"，执行系统调用，然后切换回来).为了在面对异常和异步调用时保持安全，它向函数所需的堆栈空间添加了一个惊人的常量，目前大约 500 字节，旨在涵盖 x86-32 完整的上下文保存，根据 Windows 32 体验校准.

The compiler's code generator can compute how much stack space is needed by the function itself; that's messy but straightforward and it already does that well. There's no problem with stack demands from OS calls; my functions don't make any (if that's needed, the code switches to a standard "big stack", does the system calls, and then switches back). To be safe in the face of exceptions and asynchronous calls, it adds an egregious constant, presently about 500 bytes to that stack space needed by a function, intended to cover a x86-32 complete context save, calibrated from windows 32 experience.

这种语言和异步异常处理都在 x86-32 系统上运行良好.在 x86-64 系统上运行这个 32 位实现时，我们偶尔会遇到问题.我怀疑异常时堆栈溢出.

This language and the asynch exception handling all work great on x86-32 systems. We have occasional problems running this 32 bit implementation on x86-64 systems. I suspect a stack overflow on an exception.

问题是，当在 Windows 64 机器上运行我的 32 位实现时，Windows 可以为(除以零)硬件异常或 StopThread 调用推送多少堆栈?我很紧张 Windows 推送一个完整的 x86-64 上下文，它比 x86-32 上下文大得多.有人知道吗?有没有文件可以回答这一章和经文?

The question is, how much can Windows push onto a stack for a (divide by zero) hardware exception, or a StopThread call, when running my 32 bit implementation on a Windows 64 box? I'm nervous that Windows pushes a complete x86-64 context, which is way bigger than an x86-32 context. Does anybody know? Is there a document that answers this chapter-and-verse?

我正准备进行一些动态实验来看看.

I'm about ready to run some dynamic experiments to see.

推荐答案

相同的堆栈上下文，如果您在 x64 盒子上谈论模拟 x32 环境，那么它与 x32 上的大小完全相同，在我的例子中是 0x3E0字节对齐到 DWORD.

The same stack context, if you talking about emulated x32 environment on a x64 box, then its exactly the same size as on a x32 which in my case is 0x3E0 bytes aligned to DWORD.

在 WOW64 进程上模拟的所有内容都应该在 x32 对应部分进行完全相同的处理，至少在功能方面，现在如果您依赖 TEB32 来检查堆栈，这是一种不同的情况，正如您在本文中看到的那样:

Everything emulated on WOW64 process should be handled exactly the same at is x32 counter part at least when it comes to functionality, now if you rely on TEB32 for inspect the stack that is a different case, as you can see on this article:

http://www.dumpanalysis.org/blog/index.php/2009/07/07/raw-stack-dump-of-wow64-process/

很遗憾，我找不到关于您的问题的官方文件.

Sadly there isn't an official paper i could find regarding your question.

您还可以阅读一篇关于 WOW64 模拟过程的有趣论文:

Also here is an interesting paper you can read regarding WOW64 emulated process:

http://blog.rewolf.pl/blog/?p=102#.UBTmHaBEUXw

最后，如果你的意思是有一个堆栈函数来处理异常，它可以毫无顾虑地完成，我可以在这里看到异常触发后的跟踪日志，堆栈中的某些函数是如何接收异常的在我的 SEH 之前，它似乎是某种 Avast 引擎或者一些间谍软件，我无法将它追踪到任何已知模块，因为在函数传递之后，它被释放了.

Finally if what you meant is to have an stack made function to handle exceptions it can be done without any worry, i can see here on trace logs after the exception is trigger, how some function made in stack, is receiving the exception before the mine SEH, it seems to be some kind of Avast engine or maybe some spyware, i cant trace it to any knowed module since after the function pass, it is dealloced.

希望我对某些事情有所帮助.

Hope that i've helped on something.

PS:如果您可以发布一些额外的信息，例如堆栈日志和处理异常的函数，我们可以提供更多帮助.

PS: If you can post some extra info maybe the stack log and your function to handle exceptions, we could help more.

这篇关于在 Windows x86-64 下异常时将多少推入 32 位堆栈?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！