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.

Sign up for GitHub

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

Jump to bottom

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

Closed
rasky opened this issue Apr 25, 2017 · 1 comment
Closed

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

rasky opened this issue Apr 25, 2017 · 1 comment
Labels
FrozenDueToAge

Comments

@rasky
Copy link
Member

rasky commented Apr 25, 2017 •
edited

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
runtime.markroot.func1()
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/mgcmark.go:264 +0x6d
runtime.systemstack(0x700005e30dd0)
	/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
runtime.gcBgMarkWorker.func2()
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/mgc.go:1534 +0x86
runtime.systemstack(0xc42001c000)
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/asm_amd64.s:327 +0x79
runtime.mstart()
	/usr/local/Cellar/go/1.8.1/libexec/src/runtime/proc.go:1132

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
@randall77
Copy link
Contributor

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.

@taowen taowen mentioned this issue Mar 17, 2018
Open
@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.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@rasky @randall77 @gopherbot