如何使用GDB正确调试`go test -c`生成的二进制文件？

Question

该go test命令支持该-c标志,描述如下:

-c  Compile the test binary to pkg.test but do not run it.
    (Where pkg is the last element of the package's import path.)

据我所知,生成这样的二进制文件是使用GDB以交互方式运行它的方法.但是,由于测试二进制文件是通过在某些/ tmp /目录中临时组合源文件和测试文件来创建的,所以当我list在gdb中运行时会发生这种情况:

Loading Go Runtime support.
(gdb) list
42      github.com/<username>/<project>/_test/_testmain.go: No such file or directory.

这意味着我不能像以前那样愉快地检查GDB中的Go源代码.我知道可以通过将-work标志传递给go test命令来强制临时目录保留,但是由于二进制文件不是在该目录中创建的,因此仍然是一个巨大的麻烦.我想知道是否有人找到了解决这个问题的干净方案.

Answer 1

不幸的是，这似乎是一个无法解决的已知问题。请参阅此讨论：

https://groups.google.com/forum/#!topic/golang-nuts/nIA09gp3eNU

我见过这个问题的两种解决方案。

1) 使用 set replacement-path 命令创建 .gdbinit 文件，将 gdb 重定向到源的实际位置。该文件可以由 go 工具生成，但您可能会覆盖某人的自定义 .gdbinit 文件，并将 go 工具与 gdb 绑定在一起，这似乎是一个坏主意。

2) 将可执行文件中的源文件路径（指向 /tmp/...）替换为它们在磁盘上驻留的位置。如果实际路径比 /tmp/... 路径短，这很简单。这可能需要编译器/链接器的额外支持以使该解决方案更加通用。

它在 Go Google Code 问题跟踪器上引发了这个问题，最终的决定是：

https://code.google.com/p/go/issues/detail?id=2881

这很烦人，但它是众多烦人的可能性中最不重要的一个。一般来说，go 工具不应该在源目录中乱写乱画，这些目录甚至可能是不可写的，并且退出后也不应该在其他地方留下文件。_testmain.go 中几乎没有什么有趣的东西。使用 gdb 进行测试的人可能会在testing.Main 上中断。

拉斯状态：不幸

所以，简而言之，它很糟糕，虽然你可以解决它并且 GDB 是一个测试可执行文件，但开发团队不太可能让它变得对你来说那么简单。