Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
erifan opened this issue Apr 16, 2019 · 4 comments

Comments

Projects
None yet
3 participants
@erifan
Copy link
Contributor

commented Apr 16, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 16, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Apr 17, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 17, 2019

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

This comment has been minimized.

Copy link

commented Apr 17, 2019

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

@gopherbot gopherbot closed this in 4312a18 Apr 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.