Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
madCdan opened this issue Jul 13, 2021 · 5 comments · May be fixed by #47167
Closed

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

madCdan opened this issue Jul 13, 2021 · 5 comments · May be fixed by #47167

Comments

@madCdan
Copy link

@madCdan madCdan commented Jul 13, 2021

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
Copy link

@gopherbot gopherbot commented Jul 13, 2021

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

Loading

@bcmills
Copy link
Member

@bcmills bcmills commented Jul 13, 2021

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.)

Loading

@ianlancetaylor
Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Jul 13, 2021

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

Loading

@cherrymui
Copy link
Contributor

@cherrymui cherrymui commented Jul 13, 2021

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

Loading

steeve added a commit to znly/go that referenced this issue Jul 15, 2021
Fixes golang#47166

For ELF binaries, add dwarf .eh_frame section with specific dwarf opcodes for runtime.asmcgocall.
When using cgo, this is needed to have a complete backtrace when the C code crashes ; otherwise, the backtrace stops at runtime.asmcgocall. This is due to the fact that runtime.asmcgocall switches the stack (Go stack <-> system stack).

The dwarf opcode for runtime.asmcgocall might probably be optimized.

Please note, even if the initial problem was on Android, this fixes should work on the other platforms supporting ELF binaries (tested successfully on Linux/amd64).

Change-Id: I2ef43b54127d72565bf02ed77a0e9ce883cf7545
GitHub-Last-Rev: 03206a2
GitHub-Pull-Request: golang#47167
@cherrymui cherrymui changed the title Android: Go/CGo partial backtrace cmd/link, runtime: support Go/CGo partial backtrace on Android Jul 15, 2021
@cherrymui cherrymui added this to the Unplanned milestone Jul 15, 2021
@gopherbot
Copy link

@gopherbot gopherbot commented Aug 15, 2021

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.)

Loading

@gopherbot gopherbot closed this Aug 15, 2021
steeve added a commit to znly/go that referenced this issue Aug 19, 2021
Fixes golang#47166

For ELF binaries, add dwarf .eh_frame section with specific dwarf opcodes for runtime.asmcgocall.
When using cgo, this is needed to have a complete backtrace when the C code crashes ; otherwise, the backtrace stops at runtime.asmcgocall. This is due to the fact that runtime.asmcgocall switches the stack (Go stack <-> system stack).

The dwarf opcode for runtime.asmcgocall might probably be optimized.

Please note, even if the initial problem was on Android, this fixes should work on the other platforms supporting ELF binaries (tested successfully on Linux/amd64).

Change-Id: I2ef43b54127d72565bf02ed77a0e9ce883cf7545
GitHub-Last-Rev: 03206a2
GitHub-Pull-Request: golang#47167
steeve added a commit to znly/go that referenced this issue Aug 19, 2021
Fixes golang#47166

For ELF binaries, add dwarf .eh_frame section with specific dwarf opcodes for runtime.asmcgocall.
When using cgo, this is needed to have a complete backtrace when the C code crashes ; otherwise, the backtrace stops at runtime.asmcgocall. This is due to the fact that runtime.asmcgocall switches the stack (Go stack <-> system stack).

The dwarf opcode for runtime.asmcgocall might probably be optimized.

Please note, even if the initial problem was on Android, this fixes should work on the other platforms supporting ELF binaries (tested successfully on Linux/amd64).

Change-Id: I2ef43b54127d72565bf02ed77a0e9ce883cf7545
GitHub-Last-Rev: 03206a2
GitHub-Pull-Request: golang#47167
steeve added a commit to znly/go that referenced this issue Oct 28, 2021
Fixes golang#47166

For ELF binaries, add dwarf .eh_frame section with specific dwarf opcodes for runtime.asmcgocall.
When using cgo, this is needed to have a complete backtrace when the C code crashes ; otherwise, the backtrace stops at runtime.asmcgocall. This is due to the fact that runtime.asmcgocall switches the stack (Go stack <-> system stack).

The dwarf opcode for runtime.asmcgocall might probably be optimized.

Please note, even if the initial problem was on Android, this fixes should work on the other platforms supporting ELF binaries (tested successfully on Linux/amd64).

Change-Id: I2ef43b54127d72565bf02ed77a0e9ce883cf7545
GitHub-Last-Rev: 03206a2
GitHub-Pull-Request: golang#47167
steeve added a commit to znly/go that referenced this issue Nov 22, 2021
Fixes golang#47166

For ELF binaries, add dwarf .eh_frame section with specific dwarf opcodes for runtime.asmcgocall.
When using cgo, this is needed to have a complete backtrace when the C code crashes ; otherwise, the backtrace stops at runtime.asmcgocall. This is due to the fact that runtime.asmcgocall switches the stack (Go stack <-> system stack).

The dwarf opcode for runtime.asmcgocall might probably be optimized.

Please note, even if the initial problem was on Android, this fixes should work on the other platforms supporting ELF binaries (tested successfully on Linux/amd64).

Change-Id: I2ef43b54127d72565bf02ed77a0e9ce883cf7545
GitHub-Last-Rev: 03206a2
GitHub-Pull-Request: golang#47167
steeve added a commit to znly/go that referenced this issue Nov 22, 2021
Fixes golang#47166

For ELF binaries, add dwarf .eh_frame section with specific dwarf opcodes for runtime.asmcgocall.
When using cgo, this is needed to have a complete backtrace when the C code crashes ; otherwise, the backtrace stops at runtime.asmcgocall. This is due to the fact that runtime.asmcgocall switches the stack (Go stack <-> system stack).

The dwarf opcode for runtime.asmcgocall might probably be optimized.

Please note, even if the initial problem was on Android, this fixes should work on the other platforms supporting ELF binaries (tested successfully on Linux/amd64).

Change-Id: I2ef43b54127d72565bf02ed77a0e9ce883cf7545
GitHub-Last-Rev: 03206a2
GitHub-Pull-Request: golang#47167
steeve added a commit to znly/go that referenced this issue Nov 22, 2021
Fixes golang#47166

For ELF binaries, add dwarf .eh_frame section with specific dwarf opcodes for runtime.asmcgocall.
When using cgo, this is needed to have a complete backtrace when the C code crashes ; otherwise, the backtrace stops at runtime.asmcgocall. This is due to the fact that runtime.asmcgocall switches the stack (Go stack <-> system stack).

The dwarf opcode for runtime.asmcgocall might probably be optimized.

Please note, even if the initial problem was on Android, this fixes should work on the other platforms supporting ELF binaries (tested successfully on Linux/amd64).

Change-Id: I2ef43b54127d72565bf02ed77a0e9ce883cf7545
GitHub-Last-Rev: 03206a2
GitHub-Pull-Request: golang#47167
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

5 participants