cmd/link: how are the symbols of the same name in cgo and go processed? #31485
Labels
Comments
I think it's a bug that |
Yeah, thanks. Marking |
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. |
Change https://golang.org/cl/172498 mentions this issue: |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat 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
The text was updated successfully, but these errors were encountered: