Is arm64e differrent than ARMv8.3?

The later should be compatible with Go GC arm64.
If arm64 does not work please report what happens/or is missing to execute a arm64 Go binary on "arm64e" hardware.

Note that Go GC does not usually compile to specific optional architecture extensions with a separate GOARCH but uses runtime dispatch to use newer instructions.

The minimum requirement for arm64 is

Example for ARMv8.1 atomics:
https://go-review.googlesource.com/c/go/+/81877/

Hi martisch from what I've understand if GO already support ARMv8.3 it should already support the arm64e since in armv8.3 the pointer are authenticated which is the main feature I'm interested on. So you are suggesting I'm doing something wrong with CFLAGS/LDFLAGS when I run the compiling process?

Im suggesting that for Go GC the right GOARCH to use is arm64. By support I mean that an arm64 compiled go binary should work on ARM8.3.

However I do not think Go GC does anything special about authenticated pointers. Supporting those would be a feature request for that specific arch feature. It would be good to clarify what more precisely is wanted (just assembler instruction support, or do some kernel interfaces need to be called/wrapped differently, should go build compile C code with -msign-return-address using gcc, should Go GC itself sign all return pointers from go functions?...), why this is important in the context of Go and whether there is sufficient hardware available that uses that and would be available for testing and support.

For CFLAGS/LDFLAGS I dont know because I think Go itself would not need those to compile a pure Go binary and there hasnt been anything posted here about the compiling process used and how it fails.

Ok martisch thank you so much for the help, I'll write you back with a description about HWD distribution of chipset which support arm64e and a better description regarding the safe pointer functionality.

Cheers

I think whats first missing here is what Go should do different from today so "arm64e" is considered to be supported. Does a Go binary compiled for arm64 not work on "arm64e" devices?

As far as I know arm64e permit to sign and authenticate pointers to prevent attackers from
escalating memory corruption bugs. A arm64 binary can run on those chipset (since they are an "extension" of arm64) but they can't use the safe pointer feature.
Linux Security Summit -2017:
https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf
LLVM Developers' Meeting - 2019:
https://llvm.org/devmtg/2019-10/slides/McCall-Bougacha-arm64e.pdf

The arm64e architecture is already supported by Go in the sense that programs built for arm64 will run on arm64e.

The gc compiler does not generate any pointer authentication instructions. As far as I can tell, that shouldn't matter, except that Go programs do not have extra protection against some sorts of stack modification errors.

One situation where this matters is when building with -buildmode=c-shared. A Mach-O arm64e binary (say from a closed source program) can't load an arm64 shared object. Or at least it doesn't seems to be able to in my testing, I can't find any definitive documentation about this.

I don't know if simply tagging the shared object as arm64e would be enough to make this use case work, or if would require more significant ABI changes.

Also I don't if the situation on ELF is different.

There are three separate issues here:

1. support for generating arm64e files in the linker
2. support for the arm64e ABI in the cgo shims
3. full support for the arm64e ABI in the compiler and runtime.

The third one we will be unlikely to ever do, the first one is trivial, the second one doesn't seem too difficult. We should decide whether this is worthy of pursuit for enabling Go plugins in arm64e applications.

+cc @cherrymui

Ok, some experiments with doing the first item on the list above. After toolchain is modified to generate arm64e Mach-o binary, I can load arm64e -buildmode=c-shared Go plugins in native arm64e application, but calling into the shared object seems to hang the calling application.