You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is quite a little tower of details, but it's possible for an executable using shared libraries to crash with a "runtime: unknown pc in defer" message. Here's a diff adding a test case that fails this way:
diff --git a/misc/cgo/testshared/src/dep/asm.s b/misc/cgo/testshared/src/dep/asm.s
new file mode 100644
index 0000000..b332fe2
--- /dev/null+++ b/misc/cgo/testshared/src/dep/asm.s@@ -0,0 +1,10 @@+// Copyright 2014 The Go Authors. All rights reserved.+// Use of this source code is governed by a BSD-style+// license that can be found in the LICENSE file.++//+build !gccgo++#include "textflag.h"++TEXT ·ImplementedInAsm(SB),NOSPLIT,$0-0+ RETdiff --git a/misc/cgo/testshared/src/dep/gccgo.go b/misc/cgo/testshared/src/dep/gccgo.go
new file mode 100644
index 0000000..552ec30
--- /dev/null+++ b/misc/cgo/testshared/src/dep/gccgo.go@@ -0,0 +1,5 @@+//+build gccgo++package dep++func ImplementedInAsm() {}diff --git a/misc/cgo/testshared/src/dep/stubs.go b/misc/cgo/testshared/src/dep/stubs.go
new file mode 100644
index 0000000..036296a
--- /dev/null+++ b/misc/cgo/testshared/src/dep/stubs.go@@ -0,0 +1,5 @@+//+build !gccgo++package dep++func ImplementedInAsm()diff --git a/misc/cgo/testshared/src/exe/exe.go b/misc/cgo/testshared/src/exe/exe.go
index 34fd144..f644776 100644
--- a/misc/cgo/testshared/src/exe/exe.go+++ b/misc/cgo/testshared/src/exe/exe.go@@ -1,7 +1,12 @@
package main
-import "dep"+import (+ "dep"+ "runtime"+)
func main() {
+ defer dep.ImplementedInAsm()+ runtime.GC()
dep.V = dep.F() + 1
}
The problem seems to be that when dep is built into libdep2.so there is no ImplementedInAsm·f symbol created in libdep2.so. One is created when building exe but in the .o file it is created by a reloc against an undefined STT_FUNC symbol, which the system linker reacts to by creating a plt and putting the address of the plt stub in the ImplementedInAsm·f symbol, so the address of the PLT stub ends up in the defer slot and the runtime chokes on it.
I guess it's not exactly common to defer and assembly-implemented function implemented in another packge, but this does happens in the standard library: sync.Once defers a call to sync/atomic.StoreUint32, which is how I found the problem.
Not sure what to do about this. Maybe nothing for 1.5. But maybe even functions implemented in assembly should get a funcsym?
The text was updated successfully, but these errors were encountered:
These used to be defined at use, but that breaks when shared libraries
are involved.
For #11480.
Change-Id: I416a848754fb615c0d75f9f0ccc00723d07f7f01
Reviewed-on: https://go-review.googlesource.com/12145
Reviewed-by: Rob Pike <r@golang.org>
This is mostly Russ's https://golang.org/cl/12145 but with some extra fixes to
account for the fact that function declarations without implementations now
break shared libraries, and including my test case.
Fixesgolang#11480.
Change-Id: Iabdc2934a0378e5025e4e7affadb535eaef2c8f1
This is quite a little tower of details, but it's possible for an executable using shared libraries to crash with a "runtime: unknown pc in defer" message. Here's a diff adding a test case that fails this way:
The problem seems to be that when dep is built into libdep2.so there is no ImplementedInAsm·f symbol created in libdep2.so. One is created when building exe but in the .o file it is created by a reloc against an undefined STT_FUNC symbol, which the system linker reacts to by creating a plt and putting the address of the plt stub in the ImplementedInAsm·f symbol, so the address of the PLT stub ends up in the defer slot and the runtime chokes on it.
I guess it's not exactly common to defer and assembly-implemented function implemented in another packge, but this does happens in the standard library: sync.Once defers a call to sync/atomic.StoreUint32, which is how I found the problem.
Not sure what to do about this. Maybe nothing for 1.5. But maybe even functions implemented in assembly should get a funcsym?
The text was updated successfully, but these errors were encountered: