aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/nm
diff options
context:
space:
mode:
authorCherry Zhang <cherryyz@google.com>2019-04-30 20:47:48 -0400
committerCherry Zhang <cherryyz@google.com>2019-05-06 18:17:03 +0000
commitcc5eaf9346d49c7e51a18ecc4d80c4f0456b4742 (patch)
tree04018142e260d898b125ac017a56282f74c682a5 /src/cmd/nm
parente64241216dd141589144a07f7f68acd64dc108fe (diff)
downloadgo-cc5eaf9346d49c7e51a18ecc4d80c4f0456b4742.tar.gz
go-cc5eaf9346d49c7e51a18ecc4d80c4f0456b4742.zip
cmd/internal/obj: write package path at compile time if possible
Currently, when the compiler emits a symbol name in the object file, it uses "". for the package path of the package being compiled. This is then expanded in the linker to the actual package path. With CL 173938, it does not need an allocation if the symbol name does not need expansion. In many cases, the compiler actually knows the package path (through the -p flag), so we could just write it out in compile time, without fixing it up in the linker. This reduces allocations in the linker. In case that the package path is not known (compiler's -p flag is missing, or the object file is generated by the assembler), the linker still does the expansion. This reduces ~100MB allocations (~10% inuse_space) in linking k8s.io/kubernetes/cmd/kube-apiserver on Linux/AMD64. Also makes the linker a little faster: linking cmd/go on Linux/AMD64: Real 1.13 ± 1% 1.11 ± 1% -2.13% (p=0.000 n=10+10) User 1.17 ± 3% 1.14 ± 5% -3.14% (p=0.003 n=10+10) Sys 0.34 ±15% 0.34 ±15% ~ (p=0.986 n=10+10) The caveat is that the object files get slightly bigger. On Linux/AMD64, runtime.a gets 2.1% bigger, cmd/compile/internal/ssa (which has a longer import path) gets 2.8% bigger. This reveals that when building an unnamed plugin (e.g. go build -buildmode=plugin x.go), the go command passes different package paths to the compiler and to the linker. Before this CL there seems nothing obviously broken, but given that the compiler already emits the package's import path in various places (e.g. debug info), I guess it is possible that this leads to some unexpected behavior. Now that the compiler writes the package path in more places, this disagreement actually leads to unresolved symbols. Adjust the go command to use the same package path for both compiling and linking. Change-Id: I19f08981f51db577871c906e08d9e0fd588a2dd8 Reviewed-on: https://go-review.googlesource.com/c/go/+/174657 Reviewed-by: Austin Clements <austin@google.com>
Diffstat (limited to 'src/cmd/nm')
-rw-r--r--src/cmd/nm/nm_test.go8
1 files changed, 4 insertions, 4 deletions
diff --git a/src/cmd/nm/nm_test.go b/src/cmd/nm/nm_test.go
index e47d57d9cb..dcd9f36005 100644
--- a/src/cmd/nm/nm_test.go
+++ b/src/cmd/nm/nm_test.go
@@ -266,12 +266,12 @@ func testGoLib(t *testing.T, iscgo bool) {
Found bool
}
var syms = []symType{
- {"B", "%22%22.Testdata", false, false},
- {"T", "%22%22.Testfunc", false, false},
+ {"B", "mylib.Testdata", false, false},
+ {"T", "mylib.Testfunc", false, false},
}
if iscgo {
- syms = append(syms, symType{"B", "%22%22.TestCgodata", false, false})
- syms = append(syms, symType{"T", "%22%22.TestCgofunc", false, false})
+ syms = append(syms, symType{"B", "mylib.TestCgodata", false, false})
+ syms = append(syms, symType{"T", "mylib.TestCgofunc", false, false})
if runtime.GOOS == "darwin" || (runtime.GOOS == "windows" && runtime.GOARCH == "386") {
syms = append(syms, symType{"D", "_cgodata", true, false})
syms = append(syms, symType{"T", "_cgofunc", true, false})