[clr-interp] Implement interpreter debugging support in CoreCLR

[kotlarmilos]

Description

This issue outlines work for debugging support on the CoreCLR interpreter.

Goals (functional)

• User breakpoint support (System.Diagnostics.Debugger.Break()) [clr-interp] Add User Breakpoint Support for Interpreter Debugging #121911
• Regular breakpoints set via IDE [WIP][clr-interp] Support for managed debugger breakpoints #123251
• Stepping
• Variables, stack traces, etc.
• Exception unwinding

Other

• Enable debugger tests in CI running with CoreCLR interpreter on desktop
• Refactor current JIT debugger support to use the new HardwareExecutionControl abstraction
• Remove interpreter specific condition checks (e.g., if (pJitManager != NULL && pJitManager == ExecutionManager::GetInterpreterJitManager()))
  • How to handle scenarios where no JitManager is available
• WASM support for interpreter debugging

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @janvorli, @kg
See info in area-owners.md if you want to be subscribed.

[jkotas]

Implement InterpreterCodeManager::GetFunctionSize() to return the IL size

This does not look right. Why should InterpreterCodeManager be in the business of returning the IL size?

[kotlarmilos]

Yes, that is probably incorrect. Is byte length of the interpreted code stream (not IL) more accurate?

[jkotas]

Yes, bytecode is the common term we use to describe the output of the interpreter compiler.