Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Implement basic support for unwinding longjmp across managed frames to match x64 and old EH behavior.
Like other Windows platforms we get our exception handler called with
STATUS_LONGJMP
exception. However, unlike 64-bit platforms we don't get the originaljmp_buf
and return value in theExceptionInformation
parameters. In order to handle the longjmp we need to return back from theProcessCLRException
call which is currently not done anywhere else.The solution is a bit of an abuse. We create our own
setjmp
trampoline fromProcessCLRException
and use that to return from lastCallCatchFunclet
at the end ofDispatchEx
. In order not to interfere with C++ unwinding we need to extract thesetjmp
into its own function with no C++ destructors on the frame.Also fix #115701 by calling
GCX_PREEMP_NO_DTOR
inPropagateLongJmpThroughNativeFrames
while I am at it.Contributes to #113985