Support debugging ARM64 processes on Apple M1

[dandanmu]

Environment data

Mac OS: osx.11.2-arm64 with chip: Apple M1
VS Code version:1.53.0
C# Extension version:1.23.9
.NET 6 arm64: 6.0.100-preview.1.21108.2

Steps to reproduce

1. Create a new project
2. Open the project in VSCode
3. Click F5 to debug the project.

Expected behavior

The project could debug succeed.

Actual behavior

Debugging project failed as unable to attach to CoreCLR. Unknown Error: 0x80131c3c.

dotnet --info output:
.NET SDK (reflecting any global.json):
Version: 6.0.100-preview.1.21108.2
Commit: 2e79ad7aed

Runtime Environment:
OS Name: Mac OS X
OS Version: 11.2
OS Platform: Darwin
RID: osx.11.0-arm64
Base Path: /usr/local/share/dotnet/sdk/6.0.100-preview.1.21108.2/

Host (useful for support):
Version: 6.0.0-preview.1.21102.12
Commit: 9b2776d481

.NET SDKs installed:
6.0.100-preview.1.21108.2 [/usr/local/share/dotnet/sdk]
.NET runtimes installed:
Microsoft.AspNetCore.App 6.0.0-preview.1.21103.6 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.0-preview.1.21102.12 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download

[gregg-miskelly]

We have started work to support this, but we are still a bit off from supporting this scenario.

[archanox]

@gregg-miskelly are the debugger changes accessible to the public for community contributions?

[gregg-miskelly]

@archanox We are still working on getting the debugger compiling, so nothing to share yet. Here are the potential work arounds depending on your situation:

• If you want to debug arm64 specific code: You could use Linux instead. The full extension (including language service) doesn't support arm/arm64 yet. But the debugger does support remote debugging to an arm/arm64 device (see Wiki).
• If you have Mac M1 hardware and you are looking for some sort of .NET tooling: In theory, the language service and debugger can run under emulation. I have not played with this scenario much myself, but some others have, at least for debugging. We already took one PR to improve this and we would likely be willing to take more.
• If you are working on code that must run on osx-arm64: currently the only option is to use LLDB with the SOS pluggin.

[lokinfey]

@gregg-miskelly Visual Studio for Mac (version 8.9 ) can debug .NETCore in Rosseta 2 ...... so OmniSharp can publish rossata2 version firstly.

[gregg-miskelly]

@lokinfey If you are talking about debugging a .NET Core app running under emulation -- that should work today.

[TomMurphyDev]

@gregg-miskelly is there a timeline for this use case to be supported i.e would be safe to assume that this should come on stream with the full release of NET 6 in November and that supporting apple silicon ?

[gregg-miskelly]

@TomMurphyDev yes, it is extremely likely that the C# extension will release osx-arm64 debugging support prior to the official .NET 6 release.

[gregg-miskelly]

This is fixed by using:

• C# Extension version 1.23.12. This is not yet official released, but there is a beta. See here for instructions on installing betas and here for the beta release.
  -AND-
• .NET Core 3.0 preview 3 or newer. See here for download link for the .NET Core SDK.

[rjmholt]

Hi all, I just tried this today, trying to debug a PowerShell osx-arm64 build using the beta O# release, but in the beginning was still getting the same error.

I switched back to osx-x64 and was prompted for the permission (unlike with osx-arm64).

Filling out that prompt and rebuilding again for arm64, I was then able to attach.

So I think there's still a smaller issue around not being prompted for permission when trying to attach for the first time to an ARM64 process perhaps.

[skyflyer]

@gregg-miskelly, reading your comments I'm assuming that debugging arm64 should work, but it does not (for me, at least :)). I can't see any logs that I could share with a specific error message (the debugger simply starts and exists, no errors) on a .net 6.0.0 project. OmniSharp log does not emit anything. Even if I turn on trace logging level.

The behavior is the same whether I launch or try to attach to a running process.

What can I do to troubleshoot / where can I get some trace logs of what is going on?

PS: the project is the most simplistic console app, created by dotnet new console with the following content:

Console.ReadLine();
Console.WriteLine("Hello world!");

[gregg-miskelly]

@skyflyer If you are having trouble, please open a new issue and include a debugger log (see instructions).

[EthanSK]

@gregg-miskelly I'm getting the same error. M1 Max vscode, .net6, latest mono preview 6.12.0.158, azure functions v4. Here is the output:

-> (C) {"command":"initialize","arguments":{"clientID":"vscode","clientName":"Visual Studio Code","adapterID":"coreclr","pathFormat":"path","linesStartAt1":true,"columnsStartAt1":true,"supportsVariableType":true,"supportsVariablePaging":true,"supportsRunInTerminalRequest":true,"locale":"en-gb","supportsProgressReporting":true,"supportsInvalidatedEvent":true,"supportsMemoryReferences":true},"type":"request","seq":1}
-> (C) {"command":"attach","arguments":{"name":"Attach to .NET Functions","type":"coreclr","request":"attach","processId":"39310","logging":{"engineLogging":false},"__configurationTarget":5,"__sessionId":"e18274bd-59bd-4a72-a677-77941bae17df"},"type":"request","seq":2}
<- (E) {"seq":4,"type":"event","event":"output","body":{"category":"console","output":"-------------------------------------------------------------------\nYou may only use the Microsoft .NET Core Debugger (vsdbg) with\nVisual Studio Code, Visual Studio or Visual Studio for Mac software\nto help you develop and test your applications.\n-------------------------------------------------------------------\n","severity":"ok"}}
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
<- (R) {"seq":5,"type":"response","request_seq":2,"success":true,"command":"attach"}
<- (E) {"seq":6,"type":"event","event":"initialized","body":{}}
-> (C) {"command":"setFunctionBreakpoints","arguments":{"breakpoints":[]},"type":"request","seq":3}
<- (R) {"seq":7,"type":"response","request_seq":3,"success":true,"command":"setFunctionBreakpoints","body":{"breakpoints":[]}}
-> (C) {"command":"setExceptionBreakpoints","arguments":{"filters":[],"filterOptions":[{"filterId":"user-unhandled"}]},"type":"request","seq":4}
<- (R) {"seq":8,"type":"response","request_seq":4,"success":true,"command":"setExceptionBreakpoints","body":{"breakpoints":[{"verified":true}]}}
-> (C) {"command":"configurationDone","type":"request","seq":5}
<- (E) {"seq":9,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/vsdbg/AttachFailed","data":{"VS.Diagnostics.Debugger.vsdbg.Distribution.Version":"21.1.0","VS.Diagnostics.Debugger.vsdbg.Distribution.Name":"Darwin","VS.Diagnostics.Debugger.vsdbg.Version":"17.0.10712.2 commit:70a83505117741ba30f92c713a4bb0d0395c3197","VS.Diagnostics.Debugger.vsdbg.OSFamily":"Darwin","VS.Diagnostics.Debugger.vsdbg.ErrorCode":-2146231236}}}
<- (E) {"seq":10,"type":"event","event":"output","body":{"category":"stderr","output":"Unable to start debugging. Failed to attach to process: Unknown Error: 0x80131c3c\n"}}
Unable to start debugging. Failed to attach to process: Unknown Error: 0x80131c3c
<- (R) {"seq":11,"type":"response","request_seq":5,"success":false,"command":"configurationDone","message":"Failed to attach to process: Unknown Error: 0x80131c3c"}
-> (C) {"command":"disconnect","arguments":{"restart":false},"type":"request","seq":6}
<- (E) {"seq":12,"type":"event","event":"output","body":{"category":"telemetry","output":"VS/Diagnostics/Debugger/vsdbg/DebugCompleted","data":{"VS.Diagnostics.Debugger.vsdbg.AdapterId":"coreclr","VS.Diagnostics.Debugger.vsdbg.Distribution.Version":"21.1.0","VS.Diagnostics.Debugger.vsdbg.Distribution.Name":"Darwin","VS.Diagnostics.Debugger.vsdbg.DebugCompleted.BreakCounter":0,"VS.Diagnostics.Debugger.vsdbg.Version":"17.0.10712.2 commit:70a83505117741ba30f92c713a4bb0d0395c3197","VS.Diagnostics.Debugger.vsdbg.OSFamily":"Darwin"}}}
<- (R) {"seq":13,"type":"response","request_seq":6,"success":true,"command":"disconnect"}

[EthanSK]

Not sure if @ChristianWeyer 's supposed solution in dotnet/runtime#54322 works for anyone. I couldn't figure out how to delete just x64, I tried deleting the x64 folder, and the dotnet uninstall cli tool's list command reported only arm64 dotnet 6 runtime, but it still didn't work for me (not sure if that's coz i deleted x64 incorrectly, or if that just doesn't fix the issue).

[gregg-miskelly]

@EthanSK If arm64 debugging isn't working for you, make sure you are using the arm64 version of VS Code. If you are, please open a new issue.

[EthanSK]

I might have to open a new issue because i'm using arm64. But before I do, I'm wondering, I don't see any arm64 version of omnisharp? Does it even exist? Doesn't that require arm64 mono, of which there is none

[gregg-miskelly]

OmniSharp (the language service) runs under emulation. The debugger (vsdbg-ui) needs to match the bitness of the target process. So if you are debugging a native arm64 process, a native arm64 version of vsdbg-ui is used.

[skyflyer]

@EthanSK, for what is worth, I had the same problem (see #4887), and then I installed arm64 version of VSCode and removed the ~/.vscode/extensions/ms-dotnettools.csharp-1.23.16 folder. That made it download arm64 binaries (in addition to x64).

You can verify that you have them by checking ls -l ~/.vscode/extensions/ms-dotnettools.csharp-1.23.16/.debugger

[EthanSK]

@ skyflyer Thanks for the tip, I followed that exactly and it didn't work. The output of ls - l is

drwxr-xr-x  248 ethansarif-kattan  staff  7936 17 Nov 17:47 arm64
-rw-r--r--    1 ethansarif-kattan  staff     0 17 Nov 17:48 install.complete
drwxr-xr-x  170 ethansarif-kattan  staff  5440 17 Nov 17:46 x86_64

Guess i'll stick to debugging with console log for now :(

[gregg-miskelly]

@EthanSK I believe that means when the extension runs dotnet --info it is not getting arm64 info come back. See here.

Again though, if you want help, please open a new issue instead of commenting on old ones...

[skyflyer]

@ skyflyer Thanks for the tip, I followed that exactly and it didn't work. The output of ls - l is

@EthanSK, this looks right to me. I'm guessing that arm64 folder contains the arm64 debugger. Try following the instructions and run it manually with ./vsdbg-ui --server --consoleLogging and configure your launch.json with "debugServer": 4711, directive (again, as per instructions).

@gregg-miskelly, I hope you don't mind the comments in an old issue...

[EthanSK]

@skyflyer Thanks for the suggestion. @gregg-miskelly I made a new issue here where I posted the output from @skyflyer 's most recent suggestion.