I’m not sure if CoreCLR already supports this, but I would love to see a standard cross-platform remote debugging interface for CoreCLR, similar to the one Mono supports. This enables remote debugging of mono on mobile and consoles and other devices. Hypothetically, if someone did a CoreCLR port/adaptation for Emscripten/LLVM/asm.js, then we could even remote debug our .net code running in the browser, through websockets perhaps.
The team is working on plan for remote debugging on Linux/Mac for CoreCLR/.NET Core. I haven’t seen it yet, but I can ask them to share the general ideas when they get closer.
When you say “standard cross-platform interface”, do you mean re-using the one Mono supports, or getting the Mono and .NET Core teams to standardize on a single one together? Is the idea that people will be able to use VS/XS/MD to debug any kind of app?
How do I debug coreclr on linux from Visual Studio RIGHT now?
I hadn’t thought beyond an interface for CoreCLR, but a single standard across both mono and core would certainly remove a lot of barriers. I just meant standard as in one well documented interface or protocol for core across all platforms it supports. If the community ports core to a new platform, then they will only need to implement the platform specific socket interface (e.g. websockets in a hypothetical asm.js/emscripten port) and not the protocol itself or the runtime hooks if any.
Got it. I’ll talk to the debugging folks and ask them to share their plans, when they have something significant to share.
Our preferred approach to managed code debugging is to build it as an extension to the existing unmanaged code debugging pipelines. We have been slowly converging to this architecture and we’d like to use it more broadly. It makes it possible to debug both managed and unmanaged code at the same time using one debugger, and allows leveraging all heavy lifting done by unmanaged debuggers around setup of (remote) debugging pipeline, attaching debugger to running process, or post mortem (dump) debugging - just to list some examples.
CoreCLR’s implementation on windows today is still a hybrid of in-process (soft) debugging and out-of-process (hard) debugging leveraging the OS’s native debug capabilities. Currently it is exposed via APIs (ICorDebug) usable in a debugger process running on the same machine rather than a protocol like Mono.
We would be open to discussions about including a protocol in CoreCLR as alternative debugging pipeline if there is enough interest and somebody out there builds it for CoreCLR. There may be other alternatives that satisfy the goal as well such as exposing a protocol from a debugger proxy process that runs on the same machine.
As for plans, nothing is concrete right now. Our first task is to figure out what diagnostics we need internally to help the developers porting the runtime implementation. Once that is underway we will shift our focus towards the debugging story for developers that build on top of the runtime.