Implement Edit-And-Continue ICorDebug API's for ARM64 .NET Core

[tommcdon]

Overview

This user story enables debuggers using .NET Core's ICorDebug interface to perform EnC & Hot Reload operations on ARM64. Our primary target is Visual Studio ARM64, and so the timing of this feature will coincide with Visual Studio ARM64's release schedule and ARM64 EnC feature enablement. Our goal is to implement the ARM64 EnC feature with full feature parity with x86/x64 EnC, and test it on an API level so that we can release it at high quality and with confidence.

Work Items

JIT team

• Investigate how ARM64 variable homing information will be packaged for EnC-enabled methods. There are multiple different ARM64 frame types. Each frame type will have a different variable home mapping, which affects the debugger's logic on handling EnC operations. Since OSR leaves a descriptor that tells the JIT hot to map registers and variables, there may be something we can leverage for variable re-homing in EnC. The output of this investigation will help us determine if we should implement the existing single-frame type contract with the debugger (used today for x86/x64) or implement a new one that packs variable home information into the data sent to the debugger.
• Implement ARM64 EnC contract. There is an implicit contract between the JIT and Debugger where code generation needs to support variable homing and IP remapping. This is implemented today on x86/x64 Windows JIT codegen. We need to implement the existing debugger/codegen EnC frame layout contract for ARM64. Once this is completed it should be possible to enable ARM64 EnC and update architecture specific code in the debugger's register update API.

Debugger team

• Update the register update function for architecture specific code remapping. Today the JIT generates multiple different types of frames for ARM64. X64 has 2 types of frames for general code execution and generates only one type of frame when EnC is enabled. Ideally the JIT will also generate one type of frame for ARM64 EnC, which will be used to copy the locals/parameters from the old method to the new one.
• Add coreclr EnC testing. Today we rely on Visual Studio's EnC testing for EnC. To date this has worked for us as there has not been many changes in this space and so the risk of regression in coreclr has been low. Now that we are adding ARM64 EnC we feel this is the right time to invest in adding EnC testing in closed source diagnostics testing for the .NET runtime. The desktop CLR has several test cases that might be something we could leverage.

What Success Looks Like

• Functional parity with x86/x64 EnC
• Testing in place to validate functionality

[ghost]

Tagging subscribers to this area: @tommcdon
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Overview

This user story enables debuggers using .NET Core's ICorDebug interface to perform EnC & Hot Reload operations on ARM64. Our primary target is Visual Studio ARM64, and so the timing of this feature will coincide with Visual Studio ARM64's release schedule and ARM64 EnC feature enablement. Our goal is to implement the ARM64 EnC feature with full feature parity with x86/x64 EnC, and test it on an API level so that we can release it at high quality and with confidence.

Work Items

JIT team

• Investigate how ARM64 variable homing information will be packaged for EnC-enabled methods. There are multiple different ARM64 frame types. Each frame type will have a different variable home mapping, which affects the debugger's logic on handling EnC operations. Since OSR leaves a descriptor that tells the JIT hot to map registers and variables, there may be something we can leverage for variable re-homing in EnC. The output of this investigation will help us determine if we should implement the existing single-frame type contract with the debugger (used today for x86/x64) or implement a new one that packs variable home information into the data sent to the debugger.
• Implement ARM64 EnC contract. There is an implicit contract between the JIT and Debugger where code generation needs to support variable homing and IP remapping. This is implemented today on x86/x64 Windows JIT codegen. We need to implement the existing debugger/codegen EnC frame layout contract for ARM64. Once this is completed it should be possible to enable ARM64 EnC and update architecture specific code in the debugger's register update API.

Debugger team

• Update the register update function for architecture specific code remapping. Today the JIT generates multiple different types of frames for ARM64. X64 has 2 types of frames for general code execution and generates only one type of frame when EnC is enabled. Ideally the JIT will also generate one type of frame for ARM64 EnC, which will be used to copy the locals/parameters from the old method to the new one.
• Add coreclr EnC testing. Today we rely on Visual Studio's EnC testing for EnC. To date this has worked for us as there has not been many changes in this space and so the risk of regression in coreclr has been low. Now that we are adding ARM64 EnC we feel this is the right time to invest in adding EnC testing in closed source diagnostics testing for the .NET runtime. The desktop CLR has several test cases that might be something we could leverage.

What Success Looks Like

• Functional parity with x86/x64 EnC
• Testing in place to validate functionality

Author:	tommcdon
Assignees:	-
Labels:	area-Diagnostics-coreclr, User Story
Milestone:	7.0.0

[tommcdon]

Closing via #69679