Closed
Description
For example:
(vivid)mwh@rugby:~/go/src$ go install -a -gcflags -l -installsuffix=noinl cmd/pack
(vivid)mwh@rugby:~/go/src$ /home/mwh/go/pkg/tool/linux_arm64/pack tv ../pkg/linux_arm64/runtime.a
runtime: newstack sp=0x4820041b60 stack=[0x4820040000, 0x4820041fc0]
morebuf={pc:0x45970 sp:0x4820041b60 lr:0x0}
sched={pc:0x4e3a8 sp:0x4820041b60 lr:0x45970 ctxt:0x0}
syscall.Syscall6(0x38, 0xffffffffffffff9c, 0x482000e160, 0x80000, 0x0, 0x0, 0x0, 0x234cc, 0x1e1c00, 0x30)
/home/mwh/go/src/syscall/asm_linux_arm64.s:36 +0x8
syscall.openat(0xffffffffffffff9c, 0x7ff883a7a8, 0x1c, 0x80000, 0x0, 0x0, 0x0, 0x0)
/home/mwh/go/src/syscall/zsyscall_linux_arm64.go:40 +0xa0
syscall.Open(0x7ff883a7a8, 0x1c, 0x80000, 0x0, 0x481ffff5f6, 0x0, 0x0)
/home/mwh/go/src/syscall/syscall_linux.go:51 +0x58
os.OpenFile(0x7ff883a7a8, 0x1c, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/mwh/go/src/os/file_unix.go:93 +0x70
os.Open(0x7ff883a7a8, 0x1c, 0x0, 0x0, 0x0)
/home/mwh/go/src/os/file.go:246 +0x4c
main.existingArchive(0x7ff883a7a8, 0x1c, 0x4820041e18)
/home/mwh/go/src/cmd/pack/pack.go:181 +0x38
main.archive(0x7ff883a7a8, 0x1c, 0x0, 0x482000a360, 0x0, 0x0, 0x202bd0)
/home/mwh/go/src/cmd/pack/pack.go:149 +0x34
main.main()
/home/mwh/go/src/cmd/pack/pack.go:74 +0x83c
fatal error: runtime: stack split at bad time
runtime stack:
runtime.throw(0x1586d0, 0x20)
/home/mwh/go/src/runtime/panic.go:527 +0x80
runtime.newstack()
/home/mwh/go/src/runtime/stack1.go:675 +0x4c4
runtime.morestack()
/home/mwh/go/src/runtime/asm_arm64.s:300 +0x5c
goroutine 1 [syscall]:
runtime.reentersyscall(0xce9b8, 0x4820041bb0)
/home/mwh/go/src/runtime/proc1.go:1831 +0x140 fp=0x4820041b90 sp=0x4820041b60
runtime.entersyscall(0x0)
/home/mwh/go/src/runtime/proc1.go:1855 +0x38 fp=0x4820041bb0 sp=0x4820041b90
syscall.Syscall6(0x38, 0xffffffffffffff9c, 0x482000e160, 0x80000, 0x0, 0x0, 0x0, 0x234cc, 0x1e1c00, 0x30)
/home/mwh/go/src/syscall/asm_linux_arm64.s:36 +0x8 fp=0x4820041bc0 sp=0x4820041bb0
syscall.openat(0xffffffffffffff9c, 0x7ff883a7a8, 0x1c, 0x80000, 0x0, 0x0, 0x0, 0x0)
/home/mwh/go/src/syscall/zsyscall_linux_arm64.go:40 +0xa0 fp=0x4820041c30 sp=0x4820041bc0
syscall.Open(0x7ff883a7a8, 0x1c, 0x80000, 0x0, 0x481ffff5f6, 0x0, 0x0)
/home/mwh/go/src/syscall/syscall_linux.go:51 +0x58 fp=0x4820041c80 sp=0x4820041c30
os.OpenFile(0x7ff883a7a8, 0x1c, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/mwh/go/src/os/file_unix.go:93 +0x70 fp=0x4820041cf0 sp=0x4820041c80
os.Open(0x7ff883a7a8, 0x1c, 0x0, 0x0, 0x0)
/home/mwh/go/src/os/file.go:246 +0x4c fp=0x4820041d30 sp=0x4820041cf0
main.existingArchive(0x7ff883a7a8, 0x1c, 0x4820041e18)
/home/mwh/go/src/cmd/pack/pack.go:181 +0x38 fp=0x4820041db0 sp=0x4820041d30
main.archive(0x7ff883a7a8, 0x1c, 0x0, 0x482000a360, 0x0, 0x0, 0x202bd0)
/home/mwh/go/src/cmd/pack/pack.go:149 +0x34 fp=0x4820041e50 sp=0x4820041db0
main.main()
/home/mwh/go/src/cmd/pack/pack.go:74 +0x83c fp=0x4820041f40 sp=0x4820041e50
runtime.main()
/home/mwh/go/src/runtime/proc.go:111 +0x2c0 fp=0x4820041f90 sp=0x4820041f40
runtime.goexit()
/home/mwh/go/src/runtime/asm_arm64.s:1012 +0x4 fp=0x4820041f90 sp=0x4820041f90
(vivid)mwh@rugby:~/go/src$
I guess something that is usually inlined needs to be marked nosplit?
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Activity
bradfitz commentedon Jul 15, 2015
Moving to Go 1.6, since arm64 and ppc64 are only preview releases in 1.5.
mwhudson commentedon Oct 4, 2015
This happens on ppc64 too.
[-]runtime: disabling inlining breaks on arm64[/-][+]runtime: disabling inlining breaks on arm64, ppc64[/+]rsc commentedon Nov 23, 2015
Looks like a missing nosplit. It would be nice to find out what exactly the pc= in the morebuf line corresponds to. That is, the output above says:
In that case it would be nice to know what
list *0x45970
said in gdb on the appropriate binary. (Or use whatever address currently gets printed.)runtime: mark {g,m,p}uintptr methods as nosplit
mwhudson commentedon Nov 23, 2015
Ah thanks for the hint -- it was one of the {g,m,p}uintptr methods. Just sent a CL marking them all nosplit.
gopherbot commentedon Nov 23, 2015
CL https://golang.org/cl/17165 mentions this issue.