In this this question, I give some background on a parallel language I have implemented. The compiler generates native x86-32 code.
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.
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.
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.
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.
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.
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.
Also here is an interesting paper you can read regarding WOW64 emulated process:
http://blog.rewolf.pl/blog/?p=102#.UBTmHaBEUXw
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: If you can post some extra info maybe the stack log and your function to handle exceptions, we could help more.