[clr-interp][debugger] Skip ResumeInUpdatedFunction for Interpreter#130069
[clr-interp][debugger] Skip ResumeInUpdatedFunction for Interpreter#130069matouskozak wants to merge 1 commit into
Conversation
|
Tagging subscribers to this area: @JulieLeeMSFT, @BrzVlad, @janvorli, @kg |
There was a problem hiding this comment.
Pull request overview
This PR changes Edit-and-Continue (EnC) remap behavior in the CoreCLR debugger controller so that when the current instruction pointer is in interpreted code (under FEATURE_INTERPRETER), the runtime does not call ResumeInUpdatedFunction, allowing execution to continue in the pre-update version of the method.
Changes:
- Detect interpreted-code execution at remap time via
EECodeInfo(GetIP(pContext)).IsInterpretedCode(). - Skip
g_pEEInterface->ResumeInUpdatedFunction(...)for interpreted code and log that the remap is being skipped. - Keep existing remap behavior for non-interpreted (JIT/native) code.
Comments suppressed due to low confidence (1)
src/coreclr/debug/ee/controller.cpp:9495
- This log message is now reachable when remap is skipped for interpreted code, but it claims we returned from ResumeInUpdatedFunction. That’s misleading and makes EnC/interpreter debugging harder to diagnose from logs. Consider changing it to describe what actually happened (skipping the EnC patch / remap).
LOG((LF_CORDB, LL_ALWAYS, "DEnCB::TP: We've returned from ResumeInUpdatedFunction"
"we're going to skip the EnC patchId:0x%zx\n", patch->patchId));
| // TODO: The interpreter does not support EnC remap. If we're in interpreted code, | ||
| // skip the remap and let execution continue in the old version. |
| EECodeInfo codeInfo(GetIP(pContext)); | ||
| if (codeInfo.IsInterpretedCode()) | ||
| { | ||
| LOG((LF_ENC, LL_ALWAYS, "DEnCBP::TP: method is interpreted, EnC remap not supported - skipping\n")); |
There was a problem hiding this comment.
Can the debugger handle this ? I'm wondering if you are modifying the current method and place a breakpoint in the new code etc. There is still old code running as well as new code, for the same source. What is the expected behavior ?
We currently do not support EnC when debugging code from CoreCLR interpreter. By skipping the
ResumeInUpdatedFunctionwe allow the changes to take place on subsequent method execution.