In golang.org/cl/171464, we cleaned up generation of .stkobj linker
symbols, but we couldn't figure out why a similar cleanup to
.args_stackmap linker symbols caused problems.
The issue is that we only need/want to generate .args_stackmap for
functions that are implemented in assembly in the same package. When
"pulling" a function from another package via //go:linkname, we can
safely skip emitting .args_stackmap, because compiling that package
will have generated it, if necessary.
Fixes #31615.
Change-Id: If8680aa7dd5b4e8f268b6b032d746f1b8536c867
Reviewed-on: https://go-review.googlesource.com/c/go/+/223238
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cuong Manh Le <cuong.manhle.vn@gmail.com>
Reviewed-by: Keith Randall <khr@golang.org>
"cmd/internal/objabi"
"cmd/internal/src"
"cmd/internal/sys"
- "fmt"
"internal/race"
"math/rand"
"sort"
)
func emitptrargsmap(fn *Node) {
- if fn.funcname() == "_" {
+ if fn.funcname() == "_" || fn.Func.Nname.Sym.Linkname != "" {
return
}
- sym := lookup(fmt.Sprintf("%s.args_stackmap", fn.funcname()))
- lsym := sym.Linksym()
+ lsym := Ctxt.Lookup(fn.Func.lsym.Name + ".args_stackmap")
nptr := int(fn.Type.ArgWidth() / int64(Widthptr))
bv := bvalloc(int32(nptr) * 2)