runtime: problem with preemption on windows arm32

[wmjb]

Go version

go version 1.17 github repo

Output of go env in your module/workspace:

set GOARCH=arm
set GOBIN=
set GOCACHE=C:\Users\User\AppData\Local\go-build
set GOENV=C:\Users\User\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=arm
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\User\go\pkg\mod
set GONOPROXY=
set GONOSUMDB=
set GOOS=windows
set GOPATH=C:\Users\User\go
set GOPRIVATE=
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=c:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=c:\go\pkg\tool\windows_arm
set GOVCS=
set GOVERSION=go1.17.13
set GCCGO=gccgo
set GOARM=7
set AR=ar
set CC=C:\llvm-mingw-20240619-ucrt-armv7\bin\armv7-w64-mingw32-gcc.exe
set CXX=C:\llvm-mingw-20240619-ucrt-armv7\bin\armv7-w64-mingw32-g++.exe
set CGO_ENABLED=0
set GOMOD=c:\source\go1.18\src\go.mod
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-marm -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=C:\Users\User\AppData\Local\Temp\go-build1006532952=/tmp/go-build -gno-record-gcc-switches

What did you do?

trying to build any version after 1.17 fails. go_bootstrap.exe faults.
started with version 1.4.3 on amd64 and cross compiled. then on arm32 device built from 1.4 up to 1.17. versions later than 1.17 eg 1.18,1.19,1.20,1.21 all exhibit same/similar failure.

What did you see happen?

Building Go cmd/dist using c:\go
Building Go toolchain1 using c:\go.
Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
Building Go toolchain2 using go_bootstrap and Go toolchain1.
fatal error: fault
[signal 0xc000001d code=0x0 addr=0x0 pc=0x14c5687]

goroutine 1 [running]:
runtime.throw({0x1642fc8, 0x5})
c:/source/go1.18/src/runtime/panic.go:992 +0x5c fp=0x1285d910 sp=0x1285d8fc pc=0x127a28c
runtime.sigpanic()
c:/source/go1.18/src/runtime/signal_windows.go:273 +0x1bc fp=0x1285d934 sp=0x1285d910 pc=0x128fe8c
cmd/go/internal/search.NewMatch(...)
c:/source/go1.18/src/cmd/go/internal/search/search.go:37
cmd/go/internal/modload.LoadPackages({0xf40088, 0x20}, {{0x128066d8, 0x0}, 0x128043cf, 0x8, {0x8, 0x4a}, 0x0, 0x0, ...}, ...)
c:/source/go1.18/src/cmd/go/internal/modload/load.go:250 +0x13f fp=0x1285daa4 sp=0x1285d938 pc=0x14c5687
runtime: unexpected return pc for cmd/go/internal/modload.LoadPackages called from 0x1c
stack: frame={sp:0x1285daa4, fp:0x1285dc10} stack=[0x12856000,0x1285e000)
0x1285da24: 0x1287a280 0x0000003e 0x0000003e 0x00000008
0x1285da34: 0x00000000 0x00000000 0x00000000 0x00555555
0x1285da44: 0x00000002 0x00000001 0x00000002 0x00000001
0x1285da54: 0x00000001 0x00000001 0x00000002 0x00000008
0x1285da64: 0x0000005c 0x00000010 0x00000200 0x00000000
0x1285da74: 0x01240000 0x00000009 0x00000000 0x12823dc0
0x1285da84: 0x00000004 0x016ecc70 0x00000001 0x00000000
0x1285da94: 0x12844264 0x00082f08 0x01478b10 <cmd/go/internal/search.CleanPatterns+0x000003b0> 0x12823df8
0x1285daa4: <0x0000001c 0x00f40088 0x00000020 0x128066d8
0x1285dab4: 0x00000000 0x128043cf 0x00000008 0x00000008
0x1285dac4: 0x0000004a 0x00000000 0x00000002 0x1283e1e0
0x1285dad4: 0x1283e1e0 0x12806698 0x12804350 0x128066c0
0x1285dae4: 0x0000000c 0x0000004a 0x0000004a 0x12860200
0x1285daf4: 0x00000008 0x016ed3ec 0x00000000 0x00000000
0x1285db04: 0x00000008 0x1281c1f0 0x1283c680 0x0124d140 <runtime.newobject+0x0000002c>
0x1285db14: 0x128043c0 0x00000010 0x0000000c 0x0160ff38
0x1285db24: 0x00000008 0x0004000b 0x00000000 0x00f49fa0
0x1285db34: 0x0000000c 0x00f40088 0x00000010 0x018c36f8
0x1285db44: 0x128043c0 0x00000000 0x00000000 0x014c5874 <cmd/go/internal/modload.LoadPackages+0x0000032c>
0x1285db54: 0x0000000c 0x0160ff38 0x01643801 0x128043c0
0x1285db64: 0x01501bbc <cmd/go/internal/load.PackagesAndErrors+0x000002d8> 0x016efaec 0x1281c0d0 0x00000000
0x1285db74: 0x00000000 0x129368c0 0x00000000 0x00000000
0x1285db84: 0x00000000 0x00000100 0x00000000 0x01000000
0x1285db94: 0x00000000 0x00000000 0x00000000 0x00000000
0x1285dba4: 0x00000000 0x1283e1e0 0x00000000 0x128043c0
0x1285dbb4: 0x013529fc <path/filepath.Clean+0x00000884> 0x00928b42 0x00000035 0x01641fc6
0x1285dbc4: 0x00000008 0x00000000 0x0000003e 0x01641fc6
0x1285dbd4: 0x00000003 0x00000004 0x00000000 0x013480f4 <strings.Replace+0x00000098>
0x1285dbe4: 0x12924c00 0x00000026 0x013480f4 <strings.Replace+0x00000098> 0x12924c02
0x1285dbf4: 0x0000001d 0x0000002f 0x00000000 0x12924c00
0x1285dc04: 0x1281c1f0 0x01293ed8 <runtime.concatstrings+0x0000010c> 0x00000026 >0x013529fc <path/filepath.Clean+0x00000884>
0x1285dc14: 0x1283e1e0 0x0000001d 0x01293fb4 <runtime.concatstrings+0x000001e8> 0x00000001
0x1285dc24: 0x01294098 <runtime.concatstring2+0x0000005c> 0x01290484 <runtime.makeslice+0x000000ac> 0x016ed0ac 0x01472cc4 <cmd/go/internal/trace.StartSpan+0x0000003c>
0x1285dc34: 0x018e779c 0x1287a190 0x129368e0 0x12804260
0x1285dc44: 0x00000001 0x01501944 <cmd/go/internal/load.PackagesAndErrors+0x00000060> 0x016efaec 0x1281c0d0
0x1285dc54: 0x00000000 0x00000000 0x00000000 0x012a5700 <runtime.exitsyscall+0x000000b8>
0x1285dc64: 0x1282a048 0x00000003 0x00000002 0x00000001
0x1285dc74: 0x00000001 0x00000000 0x00000000 0x01501b54 <cmd/go/internal/load.PackagesAndErrors+0x00000270>
0x1285dc84: 0x00000003 0x012a5644 <runtime.entersyscall+0x00000018> 0x00000000
cmd/go/internal/modload.LoadPackages({0x1283e1e0, 0x1d}, {{0x1293fb4, 0x1}, 0x1294098, 0x84, {0x16ed0ac, 0x1472cc4}, 0x9c, 0x77, ...}, ...)
c:/source/go1.18/src/cmd/go/internal/modload/load.go:343 +0x398 fp=0x1285dc10 sp=0x1285daa4 pc=0x14c58e0
go tool dist: FAILED: c:\source\go1.18\pkg\tool\windows_arm\go_bootstrap install -gcflags=all= -ldflags=all= -i cmd/asm cmd/cgo cmd/compile cmd/link: exit status 2

What did you expect to see?

go built from source.

[gabyhelp]

Related Issues and Documentation

• all: running make on windows-arm fails #32135 (closed)
• cmd/compile: fails to bootstrap with go1.21.9 at 15cec430d7 #66874 (closed)
• cmd/link: unexpected fault in bootstrap toolchain #58530 (closed)
• windows/arm: fatal error: minpc or maxpc invalid #42786 (closed)
• runtime: `hello world` build failure on windows/amd64 with go1.21.0 #61980 (closed)
• rosetta2 crash during bootstrap #42864 (closed)
• runtime: various crashes running ARM 'go' command under qemu #29325 (closed)
• runtime: can't build go distribution caused by #16272 and #16570 #17182 (closed)
• Compilation finished with exit code 2 for go 1.18.1 #53950 (closed)
• cmd/go: bootstrap with Go 1.21.x fail at tip, panic: godebug: Value of name not listed in godebugs.All: gotypesalias #64106 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[dmitshur]

Thanks for reporting. It's possible this port might have broken, as we don't have a builder to test it (issue #67308).

Are you able to test whether this issue reproduces at tip if you use a newer pre-built binary windows/arm archive, such as go1.22.5 (.zip or .msi) or go1.23rc2 (.zip or .msi), as the bootstrap?

CC @golang/windows.

[wmjb]

any cross compiled binaries 1.18 > either built by myself or downloaded from the official https://go.dev/dl/go1.23rc2.windows-arm.zip etc, don't execute properly. they simply close without outputting anything to console.

[wmjb]

to add some details. i'm running these binaries on windows 10 arm32, on an arm a9 and a15 amv7 cpu. everything up to 1.17 runs flawlessly and go builds working binaries for the platform from go source. the 1.18 bootstrap will sometimes run without display a fault if executed alone without any additional commands. it displays the help, usually on the second run of the binary. where the first run always crashes. any parameters passed to bootstrap.exe crashes.

[wmjb]

runtime: g 1: unexpected return pc for runtime.main called from 0x17a3298
stack: frame={sp:0xa430e98, fp:0xa430ee4} stack=[0xa430000,0xa431000)
0x0a430e18: 0x810cb274 0x00000000 0x014544a0 0x00000000
0x0a430e28: 0x00000000 0x0a42a000 0x00000002 0x0a486030
0x0a430e38: 0x01774488 0x00000000 0x014544a0 0x01774488
0x0a430e48: 0x00000000 0x00000000 0x00000000 0x00000000
0x0a430e58: 0x010d86ab <internal/syscall/windows.(*SymbolicLinkReparseBuffer).Path+0x00000043> 0x014544a0 0x01774488 0x00000000
0x0a430e68: 0x00000000 0x0a42a000 0x0a430e80 0x010d86ab <internal/syscall/windows.(*SymbolicLinkReparseBuffer).Path+0x00000043>
0x0a430e78: 0x00000000 0x01035018 <runtime.doInit1+0x000000d4> 0x01025b60 <runtime.main+0x00000414> 0x00000000
0x0a430e88: 0x00000000 0x0a488000 0x00002000 0x01009acc <runtime.(*gcControllerState).heapGoalInternal+0x00000040>
0x0a430e98: <0x017a3298 0xffffffff 0x7fffffff 0x00000000
0x0a430ea8: 0x00000000 0x00000000 0x00000000 0x000ef000
0x0a430eb8: 0x00000001 0x00000000 0x00000000 0x00000000
0x0a430ec8: 0x00000000 0x017a33c8 0x017a33c0 0x017a33b8
0x0a430ed8: 0x00000000 0x00000000 0x00000000 >0x00000000
0x0a430ee8: 0x00000000 0x00000000 0x00000000 0x017a32a8
0x0a430ef8: 0x00000000 0x00000000 0x00000000 0x00000000
0x0a430f08: 0x00000000 0x00fef7cc <runtime.(*mcache).nextFree+0x0000009c> 0x002d0000 0x00000000
0x0a430f18: 0x003d0000 0x00000000 0x00400000 0x00000000
0x0a430f28: 0x00ff0304 <runtime.mallocgc+0x0000099c> 0x017a32f8 0x0003a000 0x00000000
0x0a430f38: 0x00400000 0x00000000 0x003d0000 0x00000000
0x0a430f48: 0x00fe7f7c <runtime.makechan+0x0000018c> 0x00000000 0x00000000 0x00000000
0x0a430f58: 0x00000000 0x00000000 0x01369498 <cmd/go/internal/work.actionGraphJSON+0x00000030>
fatal error: unknown caller pc

runtime stack:
runtime.throw({0x149d25e, 0x11})
c:/Go/src/runtime/panic.go:1077 +0x4c fp=0x8ff628 sp=0x8ff614 pc=0x10229b4
runtime.(*unwinder).next(0x8ff694)
c:/Go/src/runtime/traceback.go:472 +0x36c fp=0x8ff678 sp=0x8ff628 pc=0x104be9c
runtime.addOneOpenDeferFrame.func1()
c:/Go/src/runtime/panic.go:648 +0x78 fp=0x8ff79c sp=0x8ff678 pc=0x1021a64
runtime.systemstack()
c:/Go/src/runtime/asm_arm.s:317 +0x60 fp=0x8ff7a0 sp=0x8ff79c pc=0x1059d24

goroutine 1 [running, locked to thread]:
runtime.systemstack_switch()
c:/Go/src/runtime/asm_arm.s:274 +0x4 fp=0xa430de8 sp=0xa430de4 pc=0x1059cb8
runtime.addOneOpenDeferFrame(0xa42a000, 0x0, 0x0)
c:/Go/src/runtime/panic.go:645 +0x70 fp=0xa430e04 sp=0xa430de8 pc=0x10219d4
panic({0x14544a0, 0x1774488})
c:/Go/src/runtime/panic.go:916 +0x284 fp=0xa430e58 sp=0xa430e04 pc=0x102239c
runtime.panicmem(...)
c:/Go/src/runtime/panic.go:261
runtime.sigpanic()
c:/Go/src/runtime/signal_windows.go:364 +0x1dc fp=0xa430e7c sp=0xa430e58 pc=0x103acc8
internal/syscall/windows.(*SymbolicLinkReparseBuffer).Path(0xffffffff)
c:/Go/src/internal/syscall/windows/reparse_windows.go:66 +0x43 fp=0xa430e98 sp=0xa430e80 pc=0x10d86ab
runtime.doInit(...)
c:/Go/src/runtime/proc.go:6702
runtime.main()
c:/Go/src/runtime/proc.go:249 +0x414 fp=0xa430ee4 sp=0xa430e98 pc=0x1025b60
runtime: g 1: unexpected return pc for runtime.main called from 0x17a3298
stack: frame={sp:0xa430e98, fp:0xa430ee4} stack=[0xa430000,0xa431000)
0x0a430e18: 0x810cb274 0x00000000 0x014544a0 0x00000000
0x0a430e28: 0x00000000 0x0a42a000 0x00000002 0x0a486030
0x0a430e38: 0x01774488 0x00000000 0x014544a0 0x01774488
0x0a430e48: 0x00000000 0x00000000 0x00000000 0x00000000
0x0a430e58: 0x010d86ab <internal/syscall/windows.(*SymbolicLinkReparseBuffer).Path+0x00000043> 0x014544a0 0x01774488 0x00000000
0x0a430e68: 0x00000000 0x0a42a000 0x0a430e80 0x010d86ab <internal/syscall/windows.(*SymbolicLinkReparseBuffer).Path+0x00000043>
0x0a430e78: 0x00000000 0x01035018 <runtime.doInit1+0x000000d4> 0x01025b60 <runtime.main+0x00000414> 0x00000000
0x0a430e88: 0x00000000 0x0a488000 0x00002000 0x01009acc <runtime.(*gcControllerState).heapGoalInternal+0x00000040>
0x0a430e98: <0x017a3298 0xffffffff 0x7fffffff 0x00000000
0x0a430ea8: 0x00000000 0x00000000 0x00000000 0x000ef000
0x0a430eb8: 0x00000001 0x00000000 0x00000000 0x00000000
0x0a430ec8: 0x00000000 0x017a33c8 0x017a33c0 0x017a33b8
0x0a430ed8: 0x00000000 0x00000000 0x00000000 >0x00000000
0x0a430ee8: 0x00000000 0x00000000 0x00000000 0x017a32a8
0x0a430ef8: 0x00000000 0x00000000 0x00000000 0x00000000
0x0a430f08: 0x00000000 0x00fef7cc <runtime.(*mcache).nextFree+0x0000009c> 0x002d0000 0x00000000
0x0a430f18: 0x003d0000 0x00000000 0x00400000 0x00000000
0x0a430f28: 0x00ff0304 <runtime.mallocgc+0x0000099c> 0x017a32f8 0x0003a000 0x00000000
0x0a430f38: 0x00400000 0x00000000 0x003d0000 0x00000000
0x0a430f48: 0x00fe7f7c <runtime.makechan+0x0000018c> 0x00000000 0x00000000 0x00000000
0x0a430f58: 0x00000000 0x00000000 0x01369498 <cmd/go/internal/work.actionGraphJSON+0x00000030>

goroutine 2 [force gc (idle)]:
runtime.gopark(0x14dd004, 0x177e3f0, 0x11, 0x14, 0x1)
c:/Go/src/runtime/proc.go:398 +0x104 fp=0xa431fd4 sp=0xa431fc0 pc=0x1025fc4
runtime.goparkunlock(...)
c:/Go/src/runtime/proc.go:404
runtime.forcegchelper()
c:/Go/src/runtime/proc.go:322 +0xe4 fp=0xa431fec sp=0xa431fd4 pc=0x1025e00
runtime.goexit()
c:/Go/src/runtime/asm_arm.s:859 +0x4 fp=0xa431fec sp=0xa431fec pc=0x105b93c
created by runtime.init.5 in goroutine 1
c:/Go/src/runtime/proc.go:310 +0x1c

goroutine 3 [GC sweep wait]:
runtime.gopark(0x14dd004, 0x177eba8, 0xc, 0x14, 0x1)
c:/Go/src/runtime/proc.go:398 +0x104 fp=0xa432fc4 sp=0xa432fb0 pc=0x1025fc4
runtime.goparkunlock(...)
c:/Go/src/runtime/proc.go:404
runtime.bgsweep(0xa416100)
c:/Go/src/runtime/mgcsweep.go:280 +0xa8 fp=0xa432fe4 sp=0xa432fc4 pc=0x100e194
runtime.gcenable.func1()
c:/Go/src/runtime/mgc.go:200 +0x28 fp=0xa432fec sp=0xa432fe4 pc=0xffe8a0
runtime.goexit()
c:/Go/src/runtime/asm_arm.s:859 +0x4 fp=0xa432fec sp=0xa432fec pc=0x105b93c
created by runtime.gcenable in goroutine 1
c:/Go/src/runtime/mgc.go:200 +0x74

goroutine 4 [GC scavenge wait]:
runtime.gopark(0x14dd004, 0x177ed90, 0xd, 0x14, 0x2)
c:/Go/src/runtime/proc.go:398 +0x104 fp=0xa433fb4 sp=0xa433fa0 pc=0x1025fc4
runtime.goparkunlock(...)
c:/Go/src/runtime/proc.go:404
runtime.(*scavengerState).park(0x177ed90)
c:/Go/src/runtime/mgcscavenge.go:425 +0x68 fp=0xa433fc8 sp=0xa433fb4 pc=0x100b434
runtime.bgscavenge(0xa416100)
c:/Go/src/runtime/mgcscavenge.go:653 +0x3c fp=0xa433fe4 sp=0xa433fc8 pc=0x100bb50
runtime.gcenable.func2()
c:/Go/src/runtime/mgc.go:201 +0x28 fp=0xa433fec sp=0xa433fe4 pc=0xffe84c
runtime.goexit()
c:/Go/src/runtime/asm_arm.s:859 +0x4 fp=0xa433fec sp=0xa433fec pc=0x105b93c
created by runtime.gcenable in goroutine 1
c:/Go/src/runtime/mgc.go:201 +0xbc

[gopherbot]

Change https://go.dev/cl/601777 mentions this issue: cmd/dist, internal/platform: mark windows/arm (32-bit ARM) broken

[dmitshur]

I sent CL 601777 to mark this port broken per https://go.dev/wiki/PortingPolicy#broken-ports. CC @golang/windows.

[qmuntal]

In #57960 I proposed to use the existing windows/arm64 builder to emulate a windows/arm builder. I still think it is possible, but don't have bandwidth myself to keep it up nor support the windows/arm port.

[kristibektashi]

In #57960 I proposed to use the existing windows/arm64 builder to emulate a windows/arm builder. I still think it is possible, but don't have bandwidth myself to keep it up nor support the windows/arm port.

Yes it should be possible but just remember that Windows 11 24H2 (build 26100, including Server 2025) plus it's SDK removes ARM32 support a lower version of the SDK is needed to build ARM32 apps and an earlier version of Windows is required to run them. I recommend version 22621 of the Windows SDK since it natively works on ARM64 and also still supports ARM32 applications

[wmjb]

good news, i have discovered the issue and a temporary fix until something proper can be done.
this is the commit responsible for the break c58243a

by removing the addition of the following code, the bootstrap now runs.

				sp := c.sp()
				sp -= goarch.PtrSize
				c.set_sp(sp)
				*(*uint32)(unsafe.Pointer(sp)) = uint32(c.lr())
				c.set_lr(newpc - 1)
				c.set_ip(targetPC)

[wmjb]

this builds successfully up to 1.21, there is another error in 1.22 that breaks windows arm32.

[mknyszek]

@wmjb At face value your patch doesn't make much sense. That's ripping out some functionality for asynchronous preemption, but just ripping that out is probably not correct. You can try to use GODEBUG=asyncpreemptoff=1; this will disable the relevant functionality. There is a global flag in the runtime that controls which platforms support this feature, windows/arm should probably have that flag set to false with a comment.

[wmjb]

@wmjb At face value your patch doesn't make much sense. That's ripping out some functionality for asynchronous preemption, but just ripping that out is probably not correct. You can try to use GODEBUG=asyncpreemptoff=1; this will disable the relevant functionality. There is a global flag in the runtime that controls which platforms support this feature, windows/arm should probably have that flag set to false with a comment.

a bit more investigating has revealed that if the line

go/src/runtime/os_windows.go

Line 1328 in b5ee80a

c.set_lr(newpc - 1)

is changed
from c.set_lr(newpc - 1)
to c.set_lr(newpc)

the bootstrap compiles and loads correctly also.

[qmuntal]

Hmm, that c.set_lr(newpc - 1) seems wrong, at least by looing at the comment just above:

https://github.com/golang/go/blame/6edc1c23ed078386bfbf7978f6cb5891cc2aa241/src/runtime/os_windows.go#L1319-L1323

It says that we should be subtracting 1 from IP, not from LR.

[wmjb]

Hmm, that c.set_lr(newpc - 1) seems wrong, at least by looing at the comment just above:

https://github.com/golang/go/blame/6edc1c23ed078386bfbf7978f6cb5891cc2aa241/src/runtime/os_windows.go#L1319-L1323

It says that we should be subtracting 1 from IP, not from LR.

looking at the arm64 code just below it seems there is no need to subtract 1 from IP/LR , i'm wondering why would that be needed on arm32?

so far

i've tried

c.set_lr(newpc - 1) c.set_ip(targetPC)

c.set_lr(newpc) c.set_ip(targetPC - 1)

both results in crash
however
c.set_lr(newpc) c.set_ip(targetPC)

does not result in crash and everything builds correctly and executes, the resulting go binary can then build go apps that work correctly

[gopherbot]

Change https://go.dev/cl/612555 mentions this issue: internal/releasetargets: drop 1.21 targets, add 1.24 targets

[kristibektashi]

Change https://go.dev/cl/612555 mentions this issue: internal/releasetargets: drop 1.21 targets, add 1.24 targets

There is a fix for the ARM32 Windows port but it hasn't been merged in yet. I believe @wmjb is the one who discovered the fix.

[cherrymui]

Good find. I agree that the -1 doesn't make any sense. It is not even an aligned address for PC. Interestingly, on CL 366734, when Austin, Patrik, and I reviewed it at PS 4, it was still just newpc. The -1 was added later before submission without review. If you can test that it works without the -1, feel free to send a CL. Thanks.

[wmjb]

Good find. I agree that the -1 doesn't make any sense. It is not even an aligned address for PC. Interestingly, on CL 366734, when Austin, Patrik, and I reviewed it at PS 4, it was still just newpc. The -1 was added later before submission. If you can test that it works without the -1, feel free to send a CL. Thanks.

yes it absolutely works without -1, been using go 1.23 on arm32 for some time now.

[cherrymui]

Thanks, @wmjb ! Mind sending a CL?

[wmjb]

Thanks, @wmjb ! Mind sending a CL?

#70234