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 the session below, running objdump on an amd64 executable shows source a location in a toolchain module v0.0.1-go1.23.1.darwin-arm64. Is objdump reading the wrong sources for the standard library?
(Hint to tired readers: arm64 != amd64)
xtools$ uname -m
arm64
xtools$ GOTOOLCHAIN=go1.23.1 GOOS=darwin GOARCH=amd64 go build -o ./gopls-darwin-amd64 ./gopls
xtools$ file gopls-darwin-amd64
gopls-darwin-amd64: Mach-O 64-bit executable x86_64
xtools$ go version ./gopls-darwin-amd64
./gopls-darwin-amd64: go1.23.1
xtools$ GOTOOLCHAIN=go1.23.1 go tool objdump ./gopls-darwin-amd64 | grep -A1 TEXT.*goexit
TEXT runtime.goexit1(SB) /Users/adonovan/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.1.darwin-arm64/src/runtime/proc.go
proc.go:4253 0x1045600 493b6610 CMPQ SP, 0x10(R14)
--
TEXT runtime.goexit0(SB) /Users/adonovan/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.1.darwin-arm64/src/runtime/proc.go
proc.go:4266 0x10456a0 493b6610 CMPQ SP, 0x10(R14)
--
TEXT runtime.goexit.abi0(SB) /Users/adonovan/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.23.1.darwin-arm64/src/runtime/asm_amd64.s
asm_amd64.s:1700 0x107c260 90 NOPL
--
TEXT runtime.goexit1.abi0(SB) <autogenerated>
<autogenerated>:1 0x107ec40 450f57ff XORPS X15, X15
The text was updated successfully, but these errors were encountered:
Never mind. The name of the toolchain module refers only to the OS/ARCH of the executables within it, but it should be a perfectly valid cross compiler, so consider this retracted.
I'm still confused as to why objdump doesn't report a TEXT symbol for runtime.goexit, sans suffix, as this shows up in crash reports.
I think objdump reports symbol names as in the ELF (Mach-O/PE/etc.) symbol table, whereas the stack trace reports "Go symbol names". They are usually the same, but in some rare cases they can differ, when the symbol name needs to be mangled for the ELF symbol table. The .abi0 suffix is one case.
Usually we mangle symbol names with ABI suffixes only when there is another symbol with the same name but different ABI. So in theory there probably should be an runtime.goexit (implicitly .abiinternal), but that symbol is probably never used, so it get deadcoded.
In the session below, running objdump on an amd64 executable shows source a location in a toolchain module v0.0.1-go1.23.1.darwin-arm64. Is objdump reading the wrong sources for the standard library?
(Hint to tired readers: arm64 != amd64)
The text was updated successfully, but these errors were encountered: