runtime: use ABIInternal convention in `cgocallbackg`

[ariel-anieli]

Summary

For the following instruction set architectures:

• 386 not yet, see comment
• amd64, CL 765581
• arm not yet, see comment
• arm64, CL 768780
• loong64
• mips64x not yet, see comment
• mipsx not yet, see comment
• ppc64x
• riscv64
• s390x, CL 773440

The issue tracks the changes to be done in the Go Assembly implementation of cgocallbackg. The list is built from src/runtime/asm_*.s.

The goal is to convert the ABI0 calls to cgocallbackg into ABIInternal calls.

Background

As expected, the following program panics when an unpinned pointer is passed from Go to C.

The stack trace showing an auto-generated frame by the linker.

# cat -n main.c
     1  #include <stdio.h>
     2  #include "callbackErr.h"
     3
     4  int main(void) {
     5          GoMap m = GoFoo();
     6          (void)m;
     7          return 0;
     8  }

# cat -n callbackErr.go
     1  package main
     2
     3  import (
     4          "C"
     5  )
     6
     7  //export GoFoo
     8  func GoFoo() map[int]int {
     9          return map[int]int{0: 1,}
    10  }
    11
    12  func main() {
    13  }

# go version
go version go1.26.2-X:nodwarf5 linux/amd64

# GOARCH=amd64 CC=gcc go build -buildmode=c-shared -o callbackErr.so callbackErr.go
# gcc -o main main.c callbackErr.so -Wl,-rpath,'$ORIGIN'
# ./main
[...]
goroutine 17 [running, locked to thread]:
panic({0x73b3380a0180?, 0x1dd6df238060?})
        /usr/lib/go/src/runtime/panic.go:879 +0x16f
runtime.cgoCheckArg(0x73b3380a1400, 0x1dd6df2cc060, 0x0?, 0x0, 0x1)
        /usr/lib/go/src/runtime/cgocall.go:659 +0x499
runtime.cgoCheckResult({0x73b3380a1400, 0x1dd6df2cc060})
        /usr/lib/go/src/runtime/cgocall.go:829 +0x45
_cgoexp_35a35dd190e3_GoFoo(0x7ffebc378ba0)
        /mnt/tmp/callbackErr.go:8 +0x6f
runtime.cgocallbackg1(0x73b338003000, 0x7ffebc378ba0, 0x0)
        /usr/lib/go/src/runtime/cgocall.go:466 +0x2e5
runtime.cgocallbackg(0x73b338003000, 0x7ffebc378ba0, 0x0)
        /usr/lib/go/src/runtime/cgocall.go:362 +0x132
runtime.cgocallbackg(0x73b338003000, 0x7ffebc378ba0, 0x0)
        <autogenerated>:1 +0x2b
runtime.cgocallback(0x0, 0x0, 0x0)
        /usr/lib/go/src/runtime/asm_amd64.s:1160 +0xcd
runtime.goexit({})
        /usr/lib/go/src/runtime/asm_amd64.s:1771 +0x1

The call to cgocallbackg was done using the ABI0 convention, and the linker wrapped it into an ABIInternal call.

ABI0 is a stack-based ABI; ABIInternal is register-based. See the ABIInternal specifications.

[gabyhelp]

Related Issues

• cmd/compile: switch to a register-based calling convention for Go functions #40724
• runtime/cgo: improve error message if a Go function called by C returns an unpinned pointer #75856 (closed)
• gccgo: callback from C library causes panic #6154 (closed)

Related Code Changes

• runtime/amd64: use ABIInternal convention in cgocallbackg
• runtime/arm64: use ABIInternal convention in cgocallbackg
• runtime: use ABI0 call for cgo callback
• runtime: fix uses of ABIInternal PCs in assembly
• runtime,cmd/cgo: simplify C -> Go call path
• reflect,runtime: use internal ABI for selected ASM routines

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

[randall77]

386, arm, mips* do not do abiInternal yet.

[prattmic]

The internal ABI requires that X15 is zero (see https://go.dev/s/regabi). https://go.dev/cl/765581 switched the call from cgocallback to cgocallbackg from going through the ABI wrapper to ABIInternal directly. Previously the wrapper was clearing X15, now it is cgocallback's responsibility, but this was missed in the CL.

The result is that the value of X15 from C leaks into Go code expecting it to be zero. https://go.dev/cl/770560 contains the fix and a minimum reproducer of a bad X15 value.

[gopherbot]

Change https://go.dev/cl/770560 mentions this issue: runtime: clear X15 before calling cgocallbackg

[cherrymui]

What is the motivation for this change? While we could call cgocallbackg with ABIInternal, calling the ABI0 version of it is just fine. The performance overhead of this extra call is negligible, compared to many other things in this code path. The extra frame in the traceback also doesn't seem to matter, as there are already cgo-generated frames as well as runtime frames, so it is not just user frames anyway.

Making the change doesn't hurt. But I'm not sure why we need to do this.

[ariel-anieli]

386, arm, mips* do not do abiInternal yet.

Thanks for the heads up, @randall77; I'll take heed.

[ariel-anieli]

The internal ABI requires that X15 is zero (see https://go.dev/s/regabi). https://go.dev/cl/765581 switched the call from cgocallback to cgocallbackg from going through the ABI wrapper to ABIInternal directly. Previously the wrapper was clearing X15, now it is cgocallback's responsibility, but this was missed in the CL.

The result is that the value of X15 from C leaks into Go code expecting it to be zero. https://go.dev/cl/770560 contains the fix and a minimum reproducer of a bad X15 value.

I'll pay a closer look at the ABI specs, @prattmic; your feedback is much appreciated.