Delve: Apple M1 ARM support

Created on 2 Dec 2020  路  5Comments  路  Source: go-delve/delve

Hi All

Hope you're all safe and well.

You're probably already aware of this but just in case.

When trying to debug on Apple M1, it comes back with "rosetta error: failed to allocate vm space for aot".

Just wondering if there's any recommendations please.

Love your work 馃槉馃憤

Most helpful comment

The native code has always had problems, the backend that's being used by default is in pkg/proc/gdbserial, I would focus on that.

Thanks for the pointer in the right direction. I have begun working in this direction on a second fork (https://github.com/oxisto/delve/tree/darwin-arm64-lldb) just by duplicating code for the gdbserver for arm64 now. Spawning an executable works but setting a breakpoint already crashes. I will continue working in this direction then. I will also apply for the mailing list, as you would like to move the discussion there and not on the GitHub issues if I have seen the guidelines correctly.

All 5 comments

Go doesn't officially support darwin/arm64 until go1.16, delve won't ufficially support go1.16 until 1.6.0, we don't have access to darwin/arm64 machines to port delve to them so support for delve on darwin/arm64 is unplanned. It's highly unlikely that debuggers can work through rosetta.

I have started with a darwin-arm64 branch on my fork here. https://github.com/oxisto/delve/tree/darwin-arm64

I basically just started this a couple of hours ago. The native code seems to compile (I am pretty sure it is not functional yet), but Go still throws some link errors. I am not too familiar with that kind of low level programming, so I need some more prep time to fully understand all of it.

Beware, you need a recent Go version that can compile darwin/arm64, i.e. installed using go tip.

Update : Ah, looks like I was going down the wrong route using the native backend. I think I might need to have a better understanding of delve first, I will continue with this tomorrow.

The native code has always had problems, the backend that's being used by default is in pkg/proc/gdbserial, I would focus on that.

The native code has always had problems, the backend that's being used by default is in pkg/proc/gdbserial, I would focus on that.

Thanks for the pointer in the right direction. I have begun working in this direction on a second fork (https://github.com/oxisto/delve/tree/darwin-arm64-lldb) just by duplicating code for the gdbserver for arm64 now. Spawning an executable works but setting a breakpoint already crashes. I will continue working in this direction then. I will also apply for the mailing list, as you would like to move the discussion there and not on the GitHub issues if I have seen the guidelines correctly.

Is is possible to test a fork of version currently, or is this issue still awaiting other changes? (:

Was this page helpful?
0 / 5 - 0 ratings