New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: cmd/compile, cmd/cgo: support targeting arm64_32 #60180
Comments
CC @golang/runtime |
We used to have a Native Client port that was basically x86 in a 64-bit address space with 32-bit pointers. It was a unique snowflake that broke all kinds of assumptions in the runtime and frequently broke, and I was very happy to see it removed. As a matter of policy I don't think the Go project wants to commit to another mixed-size architecture, especially just for one commercial product (the Apple Watch). If you wanted to work on an adaptation, the Go side could probably still use 64-bit data types, but then probably the main place that needs changes is where packages runtime and syscall call into macOS (or watchOS) shared libraries. Those will need to adjust the arguments appropriately. But we are unlikely to accept that port back into the main tree. |
This proposal has been added to the active column of the proposals project |
Based on the discussion above, this proposal seems like a likely decline. |
No change in consensus, so declined. |
I've tried to compile a go module using the "c-archive" mode in order to include in an Xcode project, targeted for the WatchOS (running on the Apple Watch).
After performing all the necessary steps to do so, I've discovered that it's not currently possible, due to the fact that the WatchOS is expecting binaries to target the special "ARM64_32" CPU type, which according to them means "64-bit hardware with 32-bit types".
I used the following script in my go module compilation attempt:
With the following code:
Of course, as I already said, this produces the expected binary as per the GOOS/GOARCH values, but not the one needed to run on WatchOS:
16777228 being (CPU_TYPE_ARM | CPU_ARCH_ABI64)
The correct binary format can be achieved by compiling a simple c file, targeting the correct CPU type:
Which results with the following:
33554444 being (CPU_TYPE_ARM | CPU_ARCH_ABI64_32), and CPU sutype CPU_SUBTYPE_ARM64_V8
I realize this might require some serious work to be supported, and would be happy to try and work on this myself, unfortunately this is not really my area of expertise, and I have very minimal knowledge of the golang/cgo compilation internals.
If there is no possibility this would be supported in the foreseeable future, I would be happy to receive some pointers on the areas where said work needs to be done.
On a side note, when researching this topic, I found out that support for targeting this architecture has been implemented in llvm (https://reviews.llvm.org/D99822), but seeing as gollvm does not even seem to support compiling to darwin, this seems like a dead end.
The text was updated successfully, but these errors were encountered: