Repository: go
Issue: runtime: panic not generating a correct backtrace stack while crashing in cgo on ARM64 platform
Labels: help wanted,NeedsInvestigation,arch-arm64,compiler/runtime

### Go version

go version go1.22.6 linux/amd64 (cross compile to arm64 with CGO_ENABLED=0)

### Output of `go env` in your module/workspace:

```shell
// cross compile

GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/opt/xxx/.cache/go-build'
GOENV='/opt/xxx/.config/go/env'
GOEXE=''
GOEXPERIMENT='arenas'
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/opt/xxx/gopath/pkg/mod'
GONOPROXY='xxx'
GONOSUMDB='xxx'
GOOS='linux'
GOPATH='/opt/xxx/gopath'
GOPRIVATE='xxx'
GOPROXY='xxx'
GOROOT='/opt/xxx/go'
GOSUMDB='sum.golang.google.cn'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/xxx/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.6'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/opt/xxx/inception/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build200162598=/tmp/go-build -gno-record-gcc-switches'
```


### What did you do?

I'm writing a Golang+CGO program, and testing a bad code in CGO to check if it could catch the right backtrace.

Here is my code:

`test.c`:
```
#include <stdio.h>
#include <stddef.h>
void test()
{
	int* ptr = NULL;
	*ptr = 1024;
}
void trigger_crash()
{
	printf("hello world\n");
    test();
}

```

`test.h`:
```
#ifndef FDDE6B57_4166_4D0B_9BED_C9BF03D209B8
#define FDDE6B57_4166_4D0B_9BED_C9BF03D209B8

void trigger_crash();

#endif /* FDDE6B57_4166_4D0B_9BED_C9BF03D209B8 */

```

`main.go`:
```
package main

/*
#include <test.h>
*/
import "C"
import (
	"fmt"
	"os"
	"os/signal"
	"runtime/debug"
	"syscall"
)

func enableCore() {
	debug.SetTraceback("crash")

	var lim syscall.Rlimit
	err := syscall.Getrlimit(syscall.RLIMIT_CORE, &lim)
	if err != nil {
		panic(fmt.Sprintf("error getting rlimit: %v", err))
	}
	lim.Cur = lim.Max
	fmt.Fprintf(os.Stderr, "Setting RLIMIT_CORE = %+#v\n", lim)
	err = syscall.Setrlimit(syscall.RLIMIT_CORE, &lim)
	if err != nil {
		panic(fmt.Sprintf("error setting rlimit: %v", err))
	}
	signal.Ignore(syscall.SIGABRT)
}

func main() {
	enableCore()
	C.trigger_crash()
}
```

### What did you see happen?

I cannot get the C stack by gdb on arm64.

```
$ gdb -nx -batch -ex bt cgo-crash /var/core/cgo-crash.1724899484.2105538.core
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".
Core was generated by `./cgo-crash'.
Program terminated with signal SIGABRT, Aborted.
#0  runtime.raise () at /opt/xxx/go/src/runtime/sys_linux_arm64.s:158
158     /opt/xxx/go/src/runtime/sys_linux_arm64.s: No such file or directory.
[Current thread is 1 (Thread 0x7f5b7fe1d0 (LWP 2105542))]
warning: Missing auto-load script at offset 0 in section .debug_gdb_scripts
of file /home/admin/cgo-crash.
Use `info auto-load python-scripts [REGEXP]' to list them.
#0  runtime.raise () at /opt/xxx/go/src/runtime/sys_linux_arm64.s:158
#1  0x000000000044e884 in runtime.dieFromSignal (sig=6) at /opt/xxx/go/src/runtime/signal_unix.go:923
#2  0x000000000044ef30 in runtime.sigfwdgo (sig=6, info=<optimized out>, ctx=<optimized out>, ~r0=<optimized out>) at /opt/xxx/go/src/runtime/signal_unix.go:1128
#3  0x000000000044d53c in runtime.sigtrampgo (sig=0, info=0x2020c6, ctx=0x6) at /opt/xxx/go/src/runtime/signal_unix.go:432
#4  0x0000000000469a54 in runtime.sigtramp () at /opt/xxx/go/src/runtime/sys_linux_arm64.s:462
```

Before 1.20 (included), C stack could be typed correctly. After version 1.21, this problem appeared. Related issue: https://github.com/golang/go/issues/63277

https://github.com/golang/go/commit/de5b418bea70aaf27de1f47e9b5813940d1e15a4 fixes the problem on x64. **Unfortunately, arm64 remains the problem.**

@zzkcode gave more context in https://github.com/golang/go/issues/63277#issuecomment-2316767430

### What did you expect to see?

Generating the correct backtrace on arm64 (details will be in the Details section).