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

runtime: "unexpected return pc" with JIT-generated code #20123

rasky opened this issue Apr 25, 2017 · 1 comment

runtime: "unexpected return pc" with JIT-generated code #20123

rasky opened this issue Apr 25, 2017 · 1 comment


Copy link

@rasky rasky commented Apr 25, 2017

While experimenting writing a JIT in Go (1.8), I found that the runtime complaints about the fact that my JIT-generated code does not have a stackmap.

This seems to happen in some background goroutine doing GC work. This is the full traceback:

runtime: unexpected return pc for ndsemu/arm.(*Cpu).Read32-fm called from 0x4700412
fatal error: unknown caller pc

runtime stack:
runtime.throw(0x41c0643, 0x11)
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/panic.go:596 +0x95
runtime.gentraceback(0xffffffffffffffff, 0xc42010eea0, 0x0, 0xc420074d00, 0x0, 0x0, 0x7fffffff, 0x700005e30c98, 0x0, 0x0, ...)
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/traceback.go:317 +0x13ea
runtime.scanstack(0xc420074d00, 0xc42001e528)
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/mgcmark.go:842 +0x265
runtime.scang(0xc420074d00, 0xc42001e528)
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/proc.go:866 +0x209
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/mgcmark.go:264 +0x6d
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/asm_amd64.s:343 +0xab
runtime.markroot(0xc42001e528, 0xb)
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/mgcmark.go:269 +0x1e2
runtime.gcDrain(0xc42001e528, 0xd)
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/mgcmark.go:1051 +0xbe
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/mgc.go:1534 +0x86
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/asm_amd64.s:327 +0x79

It looks like gentraceback() is called from scanstack() (not sure why). It gets confused because the JIT code is calling back into Go, so it can't fully reconstruct the traceback.

Any idea on how to work around this? My JIT code uses some stack (it's actually forced to do so, to pass arguments and save registers while calling back into Go).

@rasky rasky changed the title runtime: "missing stackmap" for JIT-generated code runtime: "unexpected return pc" with JIT-generated code Apr 25, 2017

This comment has been minimized.

Copy link

@randall77 randall77 commented Apr 25, 2017

So you're JITing code that runs on the Go stack? Not cgo or anything?
All stack frames on the Go stack must have stack frame descriptors registered with the runtime, so the garbage collector knows how to find pointers in them. It will barf if it can't find a descriptor for the frame. You'd need to register descriptors somehow. The runtime has some support for that in the form of plugin loading.

I'd rather not classify this as an issue, there's nothing here for the Go team to fix, for now at least. We don't support JITed code :) I'm going to close this and advise taking this discussion to golang-dev.

@randall77 randall77 closed this Apr 25, 2017
@taowen taowen mentioned this issue Mar 17, 2018
@golang golang locked and limited conversation to collaborators Apr 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.