seen on the gcc-13 branch 20230611 on arm-linux-gnueabi and arm-linux-gnueabihf: and all libgo tests fail on ARM32, both on the gcc-13 branch and the trunk. [...] fatal error: runtime: cannot allocate memory runtime stack: runtime.dopanic__m ../../../src/libgo/go/runtime/panic.go:1207 runtime.fatalthrow ../../../src/libgo/go/runtime/panic.go:1073 runtime.throw ../../../src/libgo/go/runtime/panic.go:1044 runtime.persistentalloc1 ../../../src/libgo/go/runtime/malloc.go:1475 runtime.persistentalloc..func1 ../../../src/libgo/go/runtime/malloc.go:1429 runtime.systemstack ../../../src/libgo/go/runtime/stubs.go:61 runtime.persistentalloc ../../../src/libgo/go/runtime/malloc.go:1428 runtime.addrRanges.init ../../../src/libgo/go/runtime/mranges.go:170 runtime.pageAlloc.init ../../../src/libgo/go/runtime/mpagealloc.go:330 runtime.mheap.init ../../../src/libgo/go/runtime/mheap.go:723 runtime.mallocinit ../../../src/libgo/go/runtime/malloc.go:497 runtime.schedinit ../../../src/libgo/go/runtime/proc.go:681 :0 :0 __libc_start_main :0 that's from a simple check: GO=go-13 WORKDIR=$(mktemp -d) trap "rm -rf $WORKDIR" 0 INT QUIT ABRT PIPE TERM cd $WORKDIR cat <<EOF > hello.go package main import "fmt" func main() { fmt.Println("hello world") } EOF $GO run hello.go $GO build hello.go echo "build: OK" ldd hello [ -x hello ] ./hello echo "run: OK"
the libgo tests also fail on powerpc-linux-gnu (for 32bit, but not for the 64bit multilibs). the tests pass on i686-linux-gnu, also the 32bit multilib tests on sparc64-linux-gnu.
The go side of the mmap C function is using the wrong type for the offset argument. Dump of assembler code for function runtime.mmap: 0xb692c340 <+0>: push {r4, r5, lr} 0xb692c344 <+4>: sub sp, sp, #20 0xb692c348 <+8>: mov r5, #0 0xb692c34c <+12>: mov r12, r1 0xb692c350 <+16>: mov r4, r0 0xb692c354 <+20>: mov r1, r2 0xb692c358 <+24>: ldr r0, [sp, #40] ; 0x28 0xb692c35c <+28>: mov r2, r3 0xb692c360 <+32>: ldr r3, [sp, #36] ; 0x24 0xb692c364 <+36>: str r0, [sp, #8] 0xb692c368 <+40>: str r3, [sp] 0xb692c36c <+44>: mov r0, r12 0xb692c370 <+48>: ldr r3, [sp, #32] 0xb692c374 <+52>: str r5, [sp, #12] 0xb692c378 <+56>: bl 0xb6454e80 <mmap@plt> => 0xb692c37c <+60>: cmn r0, #1 0xb692c380 <+64>: movne r3, r0 0xb692c384 <+68>: beq 0xb692c398 <runtime.mmap+88> 0xb692c388 <+72>: mov r0, r4 0xb692c38c <+76>: stm r4, {r3, r5} 0xb692c390 <+80>: add sp, sp, #20 0xb692c394 <+84>: pop {r4, r5, pc} 0xb692c398 <+88>: bl 0xb644b424 <runtime.errno@plt> 0xb692c39c <+92>: mov r3, r5 0xb692c3a0 <+96>: mov r5, r0 0xb692c3a4 <+100>: b 0xb692c388 <runtime.mmap+72> sp+36 is fd and sp+40 is offset. The latter is then passed as 64-bit value in sp+8/sp+12, but mmap expects a 32-bit offset. Apparently go is assuming the mmap64 interface.
The problem is in the magic comment in libgo/go/runtine/mem_gccgo.go: //extern mmap func sysMmap(addr unsafe.Pointer, n uintptr, prot, flags, fd int32, off _libgo_off_t_type) unsafe.Pointer This needs to be changed to mmap64.
Thanks. I suspect this was broken by https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604158.html.
The master branch has been updated by Ian Lance Taylor <ian@gcc.gnu.org>: https://gcc.gnu.org/g:efecb298d880cda20f8d7bea2d7b500a9752ce56 commit r14-1999-gefecb298d880cda20f8d7bea2d7b500a9752ce56 Author: Ian Lance Taylor <iant@golang.org> Date: Mon Jun 19 14:57:54 2023 -0700 runtime: use a C function to call mmap The final argument to mmap, of type off_t, varies. In CL 445375 we changed it to always use the C off_t type, but that broke 32-bit big-endian Linux systems. On those systems, using the C off_t type requires calling the mmap64 function. In C this is automatically handled by the <sys/mman.h> file. In Go, we would have to change the magic //extern comment to call mmap64 when appropriate. Rather than try to get that right, we instead go through a C function that uses C implicit type conversions to pick the right type. Fixes PR go/110297 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/504415
The releases/gcc-13 branch has been updated by Ian Lance Taylor <ian@gcc.gnu.org>: https://gcc.gnu.org/g:4ac89ab35884906900cde8172d2db74e1d913fec commit r13-7459-g4ac89ab35884906900cde8172d2db74e1d913fec Author: Ian Lance Taylor <iant@golang.org> Date: Tue Jun 20 09:56:34 2023 -0700 runtime: use a C function to call mmap The final argument to mmap, of type off_t, varies. In CL 445375 we changed it to always use the C off_t type, but that broke 32-bit big-endian Linux systems. On those systems, using the C off_t type requires calling the mmap64 function. In C this is automatically handled by the <sys/mman.h> file. In Go, we would have to change the magic //extern comment to call mmap64 when appropriate. Rather than try to get that right, we instead go through a C function that uses C implicit type conversions to pick the right type. Fixes PR go/110297 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/504415
Should be fixed now.