Skip to content

cmd/objdump: reads the wrong std sources #69390

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

Closed
adonovan opened this issue Sep 11, 2024 · 3 comments
Closed

cmd/objdump: reads the wrong std sources #69390

adonovan opened this issue Sep 11, 2024 · 3 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.

Comments

@adonovan
Copy link
Member

adonovan commented Sep 11, 2024

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		
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Sep 11, 2024
@gabyhelp
Copy link

@adonovan
Copy link
Member Author

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.

@cherrymui
Copy link
Member

cherrymui commented Sep 11, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Development

No branches or pull requests

4 participants