cmd/link: how are the symbols of the same name in cgo and go processed?

[erifan]

What version of Go are you using (go version)?

go version devel +ef38e21eb5 Sun Apr 7 18:55:23 2019 +0000 linux/arm64

Does this issue reproduce with the latest release?

Yes.

What operating system and processor architecture are you using (go env)?

go env Output

GOARCH="arm64"
GOBIN=""
GOCACHE="/home/hostname/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="arm64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/hostname/gopath"
GOPROXY=""
GORACE=""
GOROOT="/home/hostname/go-master"
GOTMPDIR=""
GOTOOLDIR="/home/hostname/go-master/pkg/tool/linux_arm64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/dev/null"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build999942006=/tmp/go-build -gno-record-gcc-switches"

What did you do?

I'm trying to enable PIE buildmode with internal linking mode on arm64 (patch url: https://go-review.googlesource.com/c/go/+/163579). The patch failed to pass the test "pie_internal_cgo" in cmd/dist/test.go. One of the reasons is that the implementation of relocation type ARM64_TLS_IE is wrong. Another reason is that the name of the function pointer (*setg_gcc) in the file runtime/cgo/gcc_linux_arm64.c is the same as the name of the function setg_gcc in the file runtime/asm_arm64.s, which causes the link or dynamic linker (I don't know the exact location) to misuse the two symbols. And then leading to another check moduledataverify1 in runtime/symtab.go fails.

When I rename the function pointer variable to a different value, and correct the implementation of relocation type ARM64_TLS_IE, all tests passed.

I have spent some time on this issue but I didn't understand how this issue produce. I think except for x86 and amd64, the issue exists on other platforms too. Any suggestion is appreciate.

/cc @cherrymui @ianlancetaylor

What did you expect to see?

All tests passed.

What did you see instead?

function symbol table not sorted by program counter: 0xaaaab8adae70 setg_gcc > 0xaaaab85febc0 runtime.abort
0xaaaab85a8000 _cgo_3298b262a8f6_Cfunc__Cmalloc
0xaaaab85a8050 _cgo_3298b262a8f6_Cfunc_free
0xaaaab85a8058 _cgo_3298b262a8f6_Cfunc_mygetgrgid_r
0xaaaab85a80a8 _cgo_3298b262a8f6_Cfunc_mygetgrnam_r
0xaaaab85a80f8 _cgo_3298b262a8f6_Cfunc_mygetpwnam_r
0xaaaab85a8148 _cgo_3298b262a8f6_Cfunc_mygetpwuid_r
0xaaaab85a8198 _cgo_3298b262a8f6_Cfunc_realloc
0xaaaab85a81e0 _cgo_3298b262a8f6_Cfunc_sysconf
0xaaaab85a8228 _cgo_3298b262a8f6_Cfunc_mygetgrouplist
0xaaaab85a8278 fatalf
.....
0xaaaab85fe8b0 gosave
0xaaaab85fe8e0 runtime.asmcgocall
0xaaaab85fe9d0 runtime.cgocallback
0xaaaab85fea20 runtime.cgocallback_gofunc
0xaaaab85feb30 _cgo_topofstack
0xaaaab85feb70 runtime.setg
0xaaaab8adae70 setg_gcc
fatal error: invalid runtime symbol table
runtime: panic before malloc heap initialized

runtime stack:
runtime.throw(0xaaaab869c2b3, 0x1c)
/home/erifan01/go-link-test/src/runtime/panic.go:714 +0x54 fp=0xffffea3924e0 sp=0xffffea3924b0 pc=0xaaaab85d31d4
runtime.moduledataverify1(0xaaaab8aad920)
/home/erifan01/go-link-test/src/runtime/symtab.go:451 +0x4c8 fp=0xffffea3925f0 sp=0xffffea3924e0 pc=0xaaaab85ed428
runtime.moduledataverify()
/home/erifan01/go-link-test/src/runtime/symtab.go:416 +0x34 fp=0xffffea392610 sp=0xffffea3925f0 pc=0xaaaab85ecf34
runtime.schedinit()
/home/erifan01/go-link-test/src/runtime/proc.go:537 +0x68 fp=0xffffea392680 sp=0xffffea392610 pc=0xaaaab85d5b48
runtime.rt0_go(0xffffea3934d6, 0x0, 0xffffea3934e2, 0xffffea39350d, 0xffffea393540, 0xffffea393560, 0xffffea393576, 0xffffea39359e, 0xffffea3935d3, 0xffffea3935e1, ...)
/home/erifan01/go-link-test/src/runtime/asm_arm64.s:70 +0xb8 fp=0xffffea3926b0 sp=0xffffea392680 pc=0xaaaab85fc198

[ianlancetaylor]

I think it's a bug that setg_gcc in runtime/cgo/gcc_linux_arm64.c is not marked static. Most of the setg_gcc variables in runtime/cgo/*.c are static, and as far as I can tell they all should be.

[erifan]

Yeah, thanks. Marking setg_gcc as static works. I will submit a patch to turn all setg_gcc variables that are not marked as static into static. In addition, I wonder if the linker needs to do something for such a naming conflict caused by a cgo variable that is not marked as static.

[ianlancetaylor]

The linker ought to report an error if it sees the same symbol name defined in multiple object files. I'm surprised that it doesn't.

[gopherbot]

Change https://golang.org/cl/172498 mentions this issue: runtime/cgo: declare variable setg_gcc as static