本文档旨在帮助开发者解决在使用 GDB 调试 Go 程序时遇到的“no debugging symbols found”问题。通过分析问题原因，并提供相应的解决方案，确保开发者能够顺利地使用 GDB 进行 Go 程序的调试。核心在于理解 -ldflags "-s" 参数的作用，并避免在调试版本中使用该参数。
问题描述
在使用 GDB 调试 Go 程序时，可能会遇到以下错误信息：
Reading symbols from /Users/xxxx...(no debugging symbols found)...done.
这表明 GDB 无法找到程序的可调试符号表，导致无法进行断点设置、变量查看等调试操作。
问题原因
该问题通常是由于在编译 Go 程序时使用了 -ldflags "-s" 参数导致的。该参数的作用是告知链接器从最终的可执行文件中移除调试信息。虽然这样做可以减小可执行文件的大小，但在调试时会导致 GDB 无法找到符号表，从而无法进行调试。
解决方案
解决该问题的关键在于不要在编译调试版本的 Go 程序时使用 -ldflags "-s" 参数。
1. 移除 -ldflags "-s" 参数：
在 go build 命令中移除 -ldflags "-s" 参数。例如，将以下命令：
go build -ldflags "-s" your_program.go
修改为：
go build your_program.go
这样编译出来的可执行文件将包含调试信息，GDB 可以正确加载符号表。
2. 针对不同构建环境使用不同的编译参数：
通常，在开发和调试阶段，我们需要保留调试信息；而在发布阶段，为了减小可执行文件的大小，可以移除调试信息。因此，建议使用不同的编译参数来区分不同的构建环境。
例如，可以使用 Makefile 或构建脚本来管理编译参数：
# Makefile
DEBUG_FLAGS =
RELEASE_FLAGS = -ldflags "-s"
debug:
go build $(DEBUG_FLAGS) your_program.go
release:
go build $(RELEASE_FLAGS) your_program.go使用 make debug 命令编译调试版本，使用 make release 命令编译发布版本。
3. 验证符号表是否包含在可执行文件中：
可以使用 objdump 命令来验证可执行文件中是否包含调试信息。
objdump -g your_program
如果输出包含调试信息，则说明符号表已经包含在可执行文件中。如果输出为空，则说明符号表被移除。
示例
假设我们有一个简单的 Go 程序 main.go:
package main
import "fmt"
func main() {
x := 10
y := 20
sum := x + y
fmt.Println("Sum:", sum)
}如果我们使用 go build -ldflags "-s" main.go 命令编译，然后使用 gdb main 命令调试，将会遇到 "no debugging symbols found" 的错误。
正确的做法是使用 go build main.go 命令编译，然后再使用 gdb main 命令调试。 此时，GDB 就可以正确加载符号表，并进行断点设置和变量查看等调试操作。
注意事项
- 确保 GDB 版本与 Go 版本兼容。
- 如果在使用了正确的编译参数后仍然遇到问题，可以尝试更新 GDB 或 Go 版本。
- 在调试过程中，可以使用 info functions 命令查看 GDB 是否正确加载了程序的函数信息。
总结
通过移除 -ldflags "-s" 参数，或者在不同构建环境中使用不同的编译参数，可以有效解决 GDB 调试 Go 程序时符号表缺失的问题。理解 -ldflags "-s" 参数的作用，并在调试版本中避免使用该参数，是成功使用 GDB 调试 Go 程序的前提。
