cmd/link, runtime: support Go/CGo partial backtrace on Android

[madCdan]

What version of Go are you using (go version)?

$ go version
go version go1.15.6 darwin/amd64

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="auto"
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/dan/Library/Caches/go-build"
GOENV="/Users/dan/Library/Application Support/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOINSECURE=""
GOMODCACHE="/Users/dan/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="darwin"
GOPATH="/Users/dan/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/Cellar/go/1.15.6/libexec"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.15.6/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
AR="ar"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
GOMOD=""
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/93/jm9qrh350x917s_37vqkvttc0000gn/T/go-build170522271=/tmp/go-build -gno-record-gcc-switches -fno-common"

What did you do?

I work for a company who uses GO/CGo code inside an Android application.
When there's a crash in the C code, the backtrace shown in the logcat (and in the error tracking tool - here, Sentry) is only partial : only the C functions are present, Go routines and Java methods are absent.

What did you expect to see?

I expect the full backtrace to be present : C functions -> Go routines -> Java methods

What did you see instead?

Only C functions in the backtrace.

NB: I worked on a fix for that, based on .eh_frame dwarf information added to the elf binary ; I'll submit a PR for that ASAP
NB2: This is linked to issue #40044

[gopherbot]

Change https://golang.org/cl/334231 mentions this issue: link: add .eh_frame section for amd64/arm64 ELF binaries

[bcmills]

IMO the whole stack really should be logically just one big stack, even though it may have segments for different languages in different parts of the heap.

But I'm curious as to why that requires a .eh_frame section — don't the frame pointers already stitch together the various different stacks? (Or does your C backtrace library not follow frame pointers, or are the Go frame pointers wrong in some way?)

(Compare runtime.SetCgoTraceback.)

[ianlancetaylor]

Most C backtrace libraries use the unwind info, not frame pointers, because most C and C++ code does not use frame pointers.

[cherrymui]

Seems like a dup of #40044 . Can we close this and move the discussion there?

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)