douwendu2460 2013-12-18 01:40
浏览 240
已采纳

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

The go test command has support for the -c flag, described as follows:

-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.)

As far as I understand, generating a binary like this is the way to run it interactively using GDB. However, since the test binary is created by combining the source and test files temporarily in some /tmp/ directory, this is what happens when I run list in gdb:

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

This means I cannot happily inspect the Go source code in GDB like I'm used to. I know it is possible to force the temporary directory to stay by passing the -work flag to the go test command, but then it is still a huge hassle since the binary is not created in that directory and such. I was wondering if anyone found a clean solution to this problem.

  • 写回答

4条回答 默认 最新

  • doubeng3412 2013-12-18 04:59
    关注

    Unfortunately, this appears to be a known issue that's not going to be fixed. See this discussion:

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

    I've seen two solutions to this problem.

    1) create a .gdbinit file with a set substitute-path command to redirect gdb to the actual location of the source. This file could be generated by the go tool but you'd risk overwriting someone's custom .gdbinit file and would tie the go tool to gdb which seems like a bad idea.

    2) Replace the source file paths in the executable (which are pointing to /tmp/...) with the location they reside on disk. This is straightforward if the real path is shorter then the /tmp/... path. This would likely require additional support from the compiler / linker to make this solution more generic.

    It spawned this issue on the Go Google Code issue tracker, to which the decision ended up being:

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

    This is annoying, but it is the least of many annoying possibilities. As a rule, the go tool should not be scribbling in the source directories, which might not even be writable, and it shouldn't be leaving files elsewhere after it exits. There is next to nothing interesting in _testmain.go. People testing with gdb can break on testing.Main instead.

    Russ Status: Unfortunate

    So, in short, it sucks, and while you can work around it and GDB a test executable, the development team is unlikely to make it as easy as it could be for you.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论
查看更多回答(3条)

报告相同问题?

悬赏问题

  • ¥15 seatunnel-web使用SQL组件时候后台报错,无法找到表格
  • ¥15 fpga自动售货机数码管(相关搜索:数字时钟)
  • ¥15 用前端向数据库插入数据,通过debug发现数据能走到后端,但是放行之后就会提示错误
  • ¥30 3天&7天&&15天&销量如何统计同一行
  • ¥30 帮我写一段可以读取LD2450数据并计算距离的Arduino代码
  • ¥15 飞机曲面部件如机翼,壁板等具体的孔位模型
  • ¥15 vs2019中数据导出问题
  • ¥20 云服务Linux系统TCP-MSS值修改?
  • ¥20 关于#单片机#的问题:项目:使用模拟iic与ov2640通讯环境:F407问题:读取的ID号总是0xff,自己调了调发现在读从机数据时,SDA线上并未有信号变化(语言-c语言)
  • ¥20 怎么在stm32门禁成品上增加查询记录功能