getisar0 SIGILL on older kernels

[maleadt]

Describe the bug

As encountered with chezmoi:

$ /home/tim/go/bin/chezmoi
SIGILL: illegal instruction
PC=0x10b91e0 m=0 sigcode=1
instruction bytes: 0x0 0x6 0x38 0xd5 0xe0 0x7 0x0 0xf9 0xc0 0x3 0x5f 0xd6 0x0 0x0 0x0 0x0

goroutine 1 gp=0x40000021c0 m=0 mp=0x38c4980 [running, locked to thread]:
github.com/tetratelabs/wazero/internal/platform.getisar0()
	/home/tim/go/pkg/mod/github.com/tetratelabs/[email protected]/internal/platform/cpuid_arm64.s:11 fp=0x40000f5dc0 sp=0x40000f5dc0 pc=0x10b91e0
github.com/tetratelabs/wazero/internal/platform.loadCpuFeatureFlags()
	/home/tim/go/pkg/mod/github.com/tetratelabs/[email protected]/internal/platform/cpuid_arm64.go:43 +0x1c fp=0x40000f5e00 sp=0x40000f5dc0 pc=0x10b8abc
github.com/tetratelabs/wazero/internal/platform.init()
	/home/tim/go/pkg/mod/github.com/tetratelabs/[email protected]/internal/platform/cpuid_arm64.go:8 +0x1c fp=0x40000f5e10 sp=0x40000f5e00 pc=0x10b89fc
runtime.doInit1(0x2d077e0)
	/opt/go/src/runtime/proc.go:7290 +0xd4 fp=0x40000f5f40 sp=0x40000f5e10 pc=0x44cc04
runtime.doInit(...)
	/opt/go/src/runtime/proc.go:7257
runtime.main()
	/opt/go/src/runtime/proc.go:254 +0x344 fp=0x40000f5fd0 sp=0x40000f5f40 pc=0x43cff4
runtime.goexit({})
	/opt/go/src/runtime/asm_arm64.s:1223 +0x4 fp=0x40000f5fd0 sp=0x40000f5fd0 pc=0x47b904

I guess this is similar to golang/go#57336, and would need a fix like golang/sys@2204b66?

Environment:

• Go version: 1.23.4
• wazero Version: 1.8.2, as depended on by chezmoi
• Host architecture: aarch64 (an old NVIDIA Jetson) running Linux 4.9

[ncruces]

I guess. But Linux 4.9 was released 8 years ago, and is EOL for 2 years. The only LTS release that still doesn't support this is 4.4 and that's already in "Super-long-term support" mode.

https://en.wikipedia.org/wiki/Linux_kernel_version_history

So, where do we draw the line?
I know we could just copy that code, but then we're stuck supporting it, and maintaining it.

My personal opinion, is I'd rather use golang/sys across the board. For this, and for everything else. It's the only way to shift (some of) the burden to someone else more qualified to make the call. But then we're not 100% zero dependency, so there's that.

[anuraaga]

BTW I noticed in the link says 4.19 is the first SLTS to support arm64 so I guess 4.4 wouldn't apply in this case either since it would be older arm and use interpreter presumably.

[ncruces]

Yeah, I'm not inclined to fix this. At most, I'd disable the check (and, so, the compiler) on older Linux. The fallback implementation is way too much.

Then someone will want us to do the same on FreeBSD, etc.