-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Fix IP adjustment for interpreter EH #117055
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix IP adjustment for interpreter EH #117055
Conversation
The exception handling stack frame iterator adjusts IP it returns for all cases when the IP represents a return address. This is to make sure that if the last instruction in a try regios is a call, it is still covered by the try region (the return address would be right after it). For jit/aoted code, throwing a software exceptions results in a call. Only hardware exceptions like division by zero etc report the address of the failing instruction. In the interpreter, when an exception is thrown, the IP address is always the address of the instruction that has triggered the exception. So we should not adjust the IP. This change fixes that by marking exception throwing frame as "faulting", which ensures the adjustment doesn't occur. That information is recorded in the InterpreterFrame when an exception is thrown by the interpreter code and cleared when the execution resumes after catch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull Request Overview
This PR fixes the IP adjustment for interpreter exception handling by marking interpreter frames as faulting when an exception is thrown, ensuring the IP remains unadjusted during interpreter exceptions. Key changes include:
- Setting faulting flags in stackwalk.cpp when an exception context is detected.
- Updating interpexec.cpp to mark interpreter frames as faulting during exception throw and rethrow.
- Introducing a new faulting flag and related setter in InterpreterFrame (frames.h and frames.cpp) and applying it in excep.cpp.
Reviewed Changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.
Show a summary per file
File | Description |
---|---|
src/coreclr/vm/stackwalk.cpp | Added faulting flag logic to set exception active context status. |
src/coreclr/vm/interpexec.cpp | Marked interpreter frames as faulting for throw and rethrow paths. |
src/coreclr/vm/frames.h | Added the m_isFaulting field and SetIsFaulting method to InterpreterFrame. |
src/coreclr/vm/frames.cpp | Updated context setting to reflect the faulting status. |
src/coreclr/vm/excep.cpp | Ensured interpreter frames are marked as faulting during unwind. |
Comments suppressed due to low confidence (1)
src/coreclr/vm/stackwalk.cpp:2863
- Consider adding a brief comment explaining why checking for CONTEXT_EXCEPTION_ACTIVE here leads to setting isInterrupted and hasFaulted. This will help maintainability by clarifying the relationship between the context flag and the interpreter frame state.
if (pRD->pCurrentContext->ContextFlags & CONTEXT_EXCEPTION_ACTIVE)
Tagging subscribers to this area: @BrzVlad, @janvorli, @kg |
The exception handling stack frame iterator adjusts IP it returns for all cases when the IP represents a return address. This is to make sure that if the last instruction in a try regios is a call, it is still covered by the try region (the return address would be right after it). For jit/aoted code, throwing a software exceptions results in a call. Only hardware exceptions like division by zero etc report the address of the failing instruction.
In the interpreter, when an exception is thrown, the IP address is always the address of the instruction that has triggered the exception. So we should not adjust the IP.
This change fixes that by marking exception throwing frame as "faulting", which ensures the adjustment doesn't occur. That information is recorded in the InterpreterFrame when an exception is thrown by the interpreter code and cleared when the execution resumes after catch.