aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/go/internal/work/build.go
diff options
context:
space:
mode:
authorCherry Zhang <cherryyz@google.com>2019-10-16 21:42:18 -0400
committerCherry Zhang <cherryyz@google.com>2019-10-21 21:57:01 +0000
commit97e497b2537d0d9588e52bb0c20df59604e6f098 (patch)
treeba97cb3393f6797389e4df066ff0f904d9bc63c5 /src/cmd/go/internal/work/build.go
parent5777ffd6e6f63647b4e4ab9a0dbfba670d2d5ced (diff)
downloadgo-97e497b2537d0d9588e52bb0c20df59604e6f098.tar.gz
go-97e497b2537d0d9588e52bb0c20df59604e6f098.zip
[dev.link] cmd: reference symbols by name when linking against Go shared library
When building a program that links against Go shared libraries, it needs to reference symbols defined in the shared library. At compile time, we don't know where the shared library boundary is. If we reference a symbol in package p by index, and package p is actually part of a shared library, we cannot resolve the index at link time, as the linker doesn't see the object file of p. So when linking against Go shared libraries, always use named reference for now. To do this, the compiler needs to know whether we will be linking against Go shared libraries. The -dynlink flag kind of indicates that (as the document says), but currently it is actually overloaded: it is also used when building a plugin or a shared library, which is self-contained (if -linkshared is not otherwise specified) and could use index for symbol reference. So we introduce another compiler flag, -linkshared, specifically for linking against Go shared libraries. The go command will pass this flag if its -linkshared flag is specified ("go build -linkshared"). There may be better way to handle this. For example, we can put the symbol indices in a special section in the shared library that the linker can read. Or we can generate some per-package description file to include the indices. (Currently we generate a .shlibname file for each package that is included in a shared library, which contains the path of the library. We could consider extending this.) That said, this CL is a stop-gap solution. And it is no worse than the old object files. If we were to redesign the build system so that the shared library boundary is known at compile time, we could use indices for symbol references that do not cross shared library boundary, as well as doing other things better. Change-Id: I9c02aad36518051cc4785dbe25c4b4cef8f3faeb Reviewed-on: https://go-review.googlesource.com/c/go/+/201818 Run-TryBot: Cherry Zhang <cherryyz@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
Diffstat (limited to 'src/cmd/go/internal/work/build.go')
-rw-r--r--src/cmd/go/internal/work/build.go4
1 files changed, 2 insertions, 2 deletions
diff --git a/src/cmd/go/internal/work/build.go b/src/cmd/go/internal/work/build.go
index 54b049b68f..6264593c34 100644
--- a/src/cmd/go/internal/work/build.go
+++ b/src/cmd/go/internal/work/build.go
@@ -97,8 +97,8 @@ and test commands:
-ldflags '[pattern=]arg list'
arguments to pass on each go tool link invocation.
-linkshared
- link against shared libraries previously created with
- -buildmode=shared.
+ build code that will be linked against shared libraries previously
+ created with -buildmode=shared.
-mod mode
module download mode to use: readonly or vendor.
See 'go help modules' for more.