cmd/go: program built by go build misses debug information in go1.21.x on darwin/amd64
#65014
Comments
CbcWestwolf
changed the title
go build misses debug information in go1.21.x on darwin/amd64
|
so how did you get the binary with the debug info? |
Use go1.20 and checkout the branch of tidb to |
|
Why do you expect those debug symbols to be present? (Where are they defined?) |
bcmills
added
OS-Darwin
GoCommand
bcmills
added
the
WaitingForInfo
TBH I am not familiar with how these debug symbols are generated and where I can define them in my go program. I found that if I upgraded to go version to go1.21, I could not debug the tidb-server. But other simpler go programs built by go1.21 contain debug info. I checked the flags for The flags seem not to disable any debug info from my understanding. I also reinstalled llvm/clang to check if it is caused by CGO. But it doesn't help. Do I miss any steps to generate debug info? |
bcmills
removed
the
WaitingForInfo
Can you clarify what you mean by that? (What command(s) were you trying to use to debug it, and what was the failure mode of the debugger?) |
bcmills
added
the
WaitingForInfo
Sure! Here are the detailed steps:
Thanks for your help! |
CbcWestwolf
changed the title
go build misses debug information in go1.21.x on darwin/amd64go build misses debug information in go1.21.x on darwin/amd64
bcmills
removed
the
WaitingForInfo
|
What C toolchain version do you use? Could you post the output of |
|
@cherrymui I have the same problem... |
|
Hmm, I have not been able to reproduce with Same for go1.22rc1. Debug info is generated. What C toolchain version do you use? I have |
|
@tttoad what is your project? Is there an easy way we can reproduce it? Thanks. |
❯ cc -v
Apple clang version 15.0.0 (clang-1500.1.0.2.5)
Target: x86_64-apple-darwin23.2.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
❯ ld -v
@(#)PROGRAM:ld PROJECT:dyld-1022.1
BUILD 13:20:30 Nov 10 2023
configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h
will use ld-classic for: armv6 armv7 armv7s arm64_32 i386 armv6m armv7k armv7m armv7em
LTO support using: LLVM version 15.0.0 (static support for 29, runtime is 29)
TAPI support using: Apple TAPI version 15.0.0 (tapi-1500.0.12.8)
Library search paths:
Framework search paths:
Here is the output of
Yes, I waited for the release of go1.21.6 and go1.22rc1. But the problem still exists...
Recently I found another repo that can reproduce this problem: git clone -b release-7.1 https://github.com/tikv/pd.git
cd pd
make build # which would build 3 binaries: pd-server, pd-ctl, and pd-recover
objdump -h bin/*Here |
|
Is it reproducible if you run
I noticed that you use a C toolchain that you installed yourself. Could you try using the one from from Xcode? Like, Thanks. |
Yes, it works! I mixed the usage of Thanks for your help! |
|
Problem solved, I also used my own installed C toolchain... thanks! @cherrymui |
|
Thanks @CbcWestwolf @tttoad for confirming! Although nothing needed to do for the Go toolchain for now, it might still be good to understand what went wrong. Like, does homebrew's C toolchain not work well with the Apple linker, in term of debug info? Would you mind running your build with Thanks. |
|
@cherrymui build with 1.20.7 build in 1.21.5 Maybe it's because of the warning. |
Yes! Simple cgo program reproduces it, while a simple pure go program does not.
Here is the output of go1.21.5 with homebrew's C toolchain: Here is the output of go1.21.5 with command line tool's C toolchain: |
|
@tttoad The warning is irrelevant (see #61229). @CbcWestwolf thank you for trying the simple cgo program, and sharing the -v output. It seems for your program (the real one, not the simple one), it uses the old Apple linker (the I'm wondering if homebrew's Thanks. |
|
Thanks for your analysis :-)
Do you mean that using the "plugin" in the project requires the old Apple linker? Is there any reference for this?
It seems that all temp files are deleted. Do I miss something? ❯ go build -x -ldflags="-tmpdir=/Users/cbcwestwolf/tmp -v" hello.go
WORK=/var/folders/p8/db9w2tpd3pvc6qwqp8rk59240000gn/T/go-build1993737340
cat /Users/cbcwestwolf/Library/Caches/go-build/0e/0e295cc05d3f638c8ef5bc3324e7f682441dee1faca8ed39ee296e8fab30c578-d # internal
# command-line-arguments
HEADER = -H1 -T0x1001000 -R0x1000
host obj copy: $WORK/b001/_pkg_.a(_x001.o) from pkg main -> /Users/cbcwestwolf/tmp/000000.o
host obj copy: $WORK/b001/_pkg_.a(_x002.o) from pkg main -> /Users/cbcwestwolf/tmp/000001.o
host obj copy: /Users/cbcwestwolf/Library/Caches/go-build/a8/a8c5cc2091c03e911d318a11fb879d38c0a11257c6b1a72df8177666464781c6-d(_x001.o) from pkg runtime/cgo -> /Users/cbcwestwolf/tmp/000002.o
host obj copy: /Users/cbcwestwolf/Library/Caches/go-build/a8/a8c5cc2091c03e911d318a11fb879d38c0a11257c6b1a72df8177666464781c6-d(_x002.o) from pkg runtime/cgo -> /Users/cbcwestwolf/tmp/000003.o
host obj copy: /Users/cbcwestwolf/Library/Caches/go-build/a8/a8c5cc2091c03e911d318a11fb879d38c0a11257c6b1a72df8177666464781c6-d(_x003.o) from pkg runtime/cgo -> /Users/cbcwestwolf/tmp/000004.o
host obj copy: /Users/cbcwestwolf/Library/Caches/go-build/a8/a8c5cc2091c03e911d318a11fb879d38c0a11257c6b1a72df8177666464781c6-d(_x004.o) from pkg runtime/cgo -> /Users/cbcwestwolf/tmp/000005.o
host obj copy: /Users/cbcwestwolf/Library/Caches/go-build/a8/a8c5cc2091c03e911d318a11fb879d38c0a11257c6b1a72df8177666464781c6-d(_x005.o) from pkg runtime/cgo -> /Users/cbcwestwolf/tmp/000006.o
host obj copy: /Users/cbcwestwolf/Library/Caches/go-build/a8/a8c5cc2091c03e911d318a11fb879d38c0a11257c6b1a72df8177666464781c6-d(_x006.o) from pkg runtime/cgo -> /Users/cbcwestwolf/tmp/000007.o
host obj copy: /Users/cbcwestwolf/Library/Caches/go-build/a8/a8c5cc2091c03e911d318a11fb879d38c0a11257c6b1a72df8177666464781c6-d(_x007.o) from pkg runtime/cgo -> /Users/cbcwestwolf/tmp/000008.o
host obj copy: /Users/cbcwestwolf/Library/Caches/go-build/a8/a8c5cc2091c03e911d318a11fb879d38c0a11257c6b1a72df8177666464781c6-d(_x008.o) from pkg runtime/cgo -> /Users/cbcwestwolf/tmp/000009.o
host obj copy: /Users/cbcwestwolf/Library/Caches/go-build/a8/a8c5cc2091c03e911d318a11fb879d38c0a11257c6b1a72df8177666464781c6-d(_x009.o) from pkg runtime/cgo -> /Users/cbcwestwolf/tmp/000010.o
host obj copy: /Users/cbcwestwolf/Library/Caches/go-build/a8/a8c5cc2091c03e911d318a11fb879d38c0a11257c6b1a72df8177666464781c6-d(_x010.o) from pkg runtime/cgo -> /Users/cbcwestwolf/tmp/000011.o
host link: "/usr/local/opt/llvm/bin/clang" "-arch" "x86_64" "-m64" "-Wl,-headerpad,1144" "-Wl,-no_pie" "-o" "/var/folders/p8/db9w2tpd3pvc6qwqp8rk59240000gn/T/go-build2120567024/b001/exe/a.out" "-Qunused-arguments" "/Users/cbcwestwolf/tmp/go.o" "/Users/cbcwestwolf/tmp/000000.o" "/Users/cbcwestwolf/tmp/000001.o" "/Users/cbcwestwolf/tmp/000002.o" "/Users/cbcwestwolf/tmp/000003.o" "/Users/cbcwestwolf/tmp/000004.o" "/Users/cbcwestwolf/tmp/000005.o" "/Users/cbcwestwolf/tmp/000006.o" "/Users/cbcwestwolf/tmp/000007.o" "/Users/cbcwestwolf/tmp/000008.o" "/Users/cbcwestwolf/tmp/000009.o" "/Users/cbcwestwolf/tmp/000010.o" "/Users/cbcwestwolf/tmp/000011.o" "-O2" "-g" "-O2" "-g" "-lpthread" "-no-pie"
59927 symbols, 18755 reachable
26346 package symbols, 22376 hashed symbols, 8328 non-package symbols, 2877 external symbols
71439 liveness data
❯ ls /Users/cbcwestwolf/tmp
I replace the Homebrew dsymutil with the Apple one by |
See #62598. There is a bug in Apple's new linker that causes plugins to fail. We changed our code generation to avoid the bug in Go tip (1.22rc1 and later). For Go 1.21, we instead worked around by forcing the old Apple linker. (I don't think this is related to this bug, though.)
That is weird. It should not delete files if
I don't think |
I don't know what happened in my environment :-( 
|
|
That is very weird. This is what I see: Trying using a Go installation from https://go.dev/dl/#go1.22rc1 , or built from source? Also try using an absolute path for the tmpdir. Thanks. |
Go version
go version go1.21.5 darwin/amd64
Output of
go envin your module/workspace:What did you do?
What did you see happen?
What did you expect to see?
The text was updated successfully, but these errors were encountered: