Description
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:
if c.ctxt.Flag_shared && c.cursym.Name != "runtime.duffzero" && c.cursym.Name != "runtime.duffcopy" {
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.
CC @mwhudson