In short, because we're never going to be able to continue, so there's no point on trying to pass because that's going to fail.
Not really, if the app handles the exception there's no reason it would fail. Not passing the exception will break things like IsBadReadPtr.
Ok. My understanding of the non-continuable flag was not correct. A fixed patch follows in a seporate e-mail to wine-patches.
In long, because I've got another patch in the pipeline (it needs some tweaking) that moves the calling of the debugger into the signal handler. It allows the debugger to catch exceptions that would previously have resulted in a total crash (non-continuable exceptions), and it more accurately reflects how the Windows debugger is called. Using a debugger will also no longer modify program memory as it does currently. In all, it should allow the debugger to work in more circumstances than it currently does.
Well, I'll wait to see the patch, but I doubt we want to do that. The current way is pretty much identical to what Windows does, and it sounds like your way isn't.
Doing SEH via the application stack is correct in the current code. Passing exceptions to the debugger via the application stack is not correct. I've attached a small C file which will demonstrate the problem. On windows, you can single step through the assembly code correctly, on Wine, you can not. The one conclusion that we can draw is that the method for calling the debugger on Windows must not use the application stack at all. Furthermore, if an exception does occur while the stack pointer is bad in windows, the debugger will trap it and let you examine the situation. Wine right now crashes.
Moving the calling of the debugger into the signal handler takes away the dependance on a correct signal stack. It lets us:
1) Debug a program without having to modify it's memory to call the debugger.
2) Set breakpoints and single step through areas where the stack pointer is incorrect.
3) Use the debugger even when the application is at it's upper stack limit (so we can see where the stack overflow exists).
4) Examine exceptions and application state when an exception is generated while stack pointer is bad.
All these can be done on Windows, and therefore sending events to the Windows debugger must be done without relying on the program stack. It would make sense for the wine debugger to be equally capable.
Now, if calling the debugger shifts positions to the signal stack, it is possible to detect whether we can deliver a corresponding SE to the applications SEH. If we can detect when the exception can not actually be delivered, then we can force the debugger to stop, even if this is the first notification of a excpetion to the debugger. The point behind the non-continuable change was to tell the debugger this. That patch was wrong. I should have used EH_STACK_INVALID (it would be impossible to even pass this flag to the debugger if the debugger relied on the application stack).
Glenn.