go: runtime: libunwind is unable to unwind CGo to Go's stack
What version of Go are you using (go version
)?
master
as of the build
$ go version devel +dd150176c3 Fri Jul 3 03:31:29 2020 +0000
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env GO111MODULE="" GOARCH="amd64" GOBIN="" GOCACHE="/Users/steeve/Library/Caches/go-build" GOENV="/Users/steeve/Library/Application Support/go/env" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOINSECURE="" GOMODCACHE="/Users/steeve/go/pkg/mod" GONOPROXY="" GONOSUMDB="" GOOS="darwin" GOPATH="/Users/steeve/go" GOPRIVATE="" GOPROXY="https://proxy.golang.org,direct" GOROOT="/Users/steeve/code/github.com/znly/go" GOSUMDB="sum.golang.org" GOTMPDIR="" GOTOOLDIR="/Users/steeve/code/github.com/znly/go/pkg/tool/darwin_amd64" GCCGO="gccgo" AR="ar" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="/Users/steeve/code/github.com/znly/go/src/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bs/51dlb_nn5k35xq9qfsxv9wc00000gr/T/go-build842228435=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
Following @cherrymui’s comment on #39524, I figured I tried to check why lots of our backtraces on iOS stop at runtime.asmcgocall
.
Since I wanted to reproduce it on my computer and lldb
manges to properly backtrace, I figured I’d give libunwind
a try, since this is was iOS uses when a program crashes.
Unfortunately libunwind
didn’t manage to walk the stack past CGo generated _Cfunc_
functions.
Given this program:
package main
/*
#cgo CFLAGS: -O0
#include <libunwind.h>
#include <stdio.h>
void backtrace() {
unw_cursor_t cursor;
unw_context_t context;
// Initialize cursor to current frame for local unwinding.
unw_getcontext(&context);
unw_init_local(&cursor, &context);
// Unwind frames one by one, going up the frame stack.
while (unw_step(&cursor) > 0) {
unw_word_t offset, pc;
unw_get_reg(&cursor, UNW_REG_IP, &pc);
if (pc == 0) {
break;
}
printf("0x%llx:", pc);
char sym[256];
if (unw_get_proc_name(&cursor, sym, sizeof(sym), &offset) == 0) {
printf(" (%s+0x%llx)\n", sym, offset);
} else {
printf(" -- error: unable to obtain symbol name for this frame\n");
}
}
}
void two() {
printf("two\n");
backtrace();
}
void one() {
printf("one\n");
two();
}
*/
import "C"
//go:noinline
func goone() {
C.one()
}
func main() {
goone()
}
It prints:
one1
two2
0x40617fe: (two+0x1e)
0x406182e: (one+0x1e)
0x406168b: (_cgo_7c45d1c2feef_Cfunc_one+0x1b)
I tried doing Go(1) -> C(1) -> Go(2) -> C(2) and backtrace, and it only unwinds C(2).
Also, I tried to make set asmcgocall
to have a 16 bytes stack, hoping that the generated frame pointer would help, but it didn’t.
What did you expect to see?
The complete backtrace.
What did you see instead?
A backtrace for C functions only.
About this issue
- Original URL
- State: open
- Created 4 years ago
- Comments: 22 (17 by maintainers)
Commits related to this issue
- runtime: use explicit NOFRAME on windows/amd64 This CL marks non-leaf nosplit assembly functions as NOFRAME to avoid relying on the implicit amd64 NOFRAME heuristic, where NOSPLIT functions without s... — committed to golang/go by qmuntal 2 years ago
- runtime: adjust frame pointer on stack copy on ARM64 Frame pointer is enabled on ARM64. When copying stacks, the saved frame pointers need to be adjusted. Updates #39524, #40044. Fixes #58432. Chan... — committed to golang/go by cherrymui 4 years ago
@steeve libunwind unwinds the stack using the unwind information, which is not DWARF but is approximately the same format as a subset of DWARF. That’s what I was referring to when I suggested that we could write unwind information for
asmcgocall
. (You can see the horrible details at https://www.airs.com/blog/archives/460).