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
In cmd/link/internal/ld/symtab.go we see this code:
if (Buildmode == BuildmodeCArchive || Buildmode == BuildmodePIE || ctxt.DynlinkingGo()) && SysArch.Family == sys.PPC64 && typ == STT_FUNC && x.Name != "runtime.duffzero" && x.Name != "runtime.duffcopy" {
// On ppc64 the top three bits of the st_other field indicate how
// many instructions separate the global and local entry points. In
// our case it is two instructions, indicated by the value 3.
other |= 3 << 5
}
This is correct provided that we do in fact separate the global and local entry points by two instructions. Those two instructions are added at compilation time by code in the function preprocess in cmd/internal/obj/ppc64/obj9.go, under these conditions:
So everything should work out provided that whenever we link with -buildmode=c-archive we compile all the input files with -shared. If we compile the input files without -shared, and then put the results into an archive with -buildmode=c-archive, the symbol table will report that there is a two instruction prologue when, in fact, there is not. Of course the resulting code will not work if put into a shared library, but that is expected since it was compiled without -shared.
When using the go tool, this does not happen, as using -buildmode=c-archive implies passing -shared to the compiler (see BuildModeInit in cmd/go/internal/work/build.go). But when building Go in some other way this actually can come up. In particular it can come up when building with Bazel (http://bazel.build), or, at least, it can once Bazel start properly supporting building Go archives.
If we want to preserve the distinction between compiling in shared mode and not, which at least for the moment I think we do for efficiency reasons, then we need to fix the linker to put the correct number in the symbol table st_other field when describing a symbol compiled without -shared.
This permits the user to override the code generation flag when they
know better. This is always a good policy for all flags automatically
inserted by the build system.
Doing this now so that I can write a test for #20290.
Update #20290
Change-Id: I5c6708a277238d571b8d037993a5a59e2a442e98
Reviewed-on: https://go-review.googlesource.com/42952
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
In cmd/link/internal/ld/symtab.go we see this code:
This is correct provided that we do in fact separate the global and local entry points by two instructions. Those two instructions are added at compilation time by code in the function
preprocess
in cmd/internal/obj/ppc64/obj9.go, under these conditions:So everything should work out provided that whenever we link with
-buildmode=c-archive
we compile all the input files with-shared
. If we compile the input files without-shared
, and then put the results into an archive with-buildmode=c-archive
, the symbol table will report that there is a two instruction prologue when, in fact, there is not. Of course the resulting code will not work if put into a shared library, but that is expected since it was compiled without-shared
.When using the go tool, this does not happen, as using
-buildmode=c-archive
implies passing-shared
to the compiler (seeBuildModeInit
in cmd/go/internal/work/build.go). But when building Go in some other way this actually can come up. In particular it can come up when building with Bazel (http://bazel.build), or, at least, it can once Bazel start properly supporting building Go archives.If we want to preserve the distinction between compiling in shared mode and not, which at least for the moment I think we do for efficiency reasons, then we need to fix the linker to put the correct number in the symbol table st_other field when describing a symbol compiled without
-shared
.CC @mwhudson
The text was updated successfully, but these errors were encountered: